4 ms·

I don't know if HALs in the kernel would have been the smart thing to do here (I'm not familiar enough with the problem to comment; generally, abstracting hardw

I don't know if HALs in the kernel would have been the smart thing to do here (I'm not familiar enough with the problem to comment; generally, abstracting hardware access behind a HAL is a smart thing, but "generally" is a really bad snare trap). On the other hand, I'd really love to see the Linux team getting the same treatment that Microsoft gets whenever they encourage lack of portability, even where portability would be irrelevant. A whole thread about this, and not once was the word "EEE" uttered. I'm sure business had nothing to do with the Linux team's decision here, I'm just a little pissed at our double standards ("our" as in the open source/free software community of users and developers). AMD's criticism is not without valid points. Getting drivers to work (let alone in upstream) while the hardware is still relevant is difficult and requires a lot of maintenance, hacking and testing due to things like API changes, undocumented/shifting ad-hoc conventions and so on. Driver development on Linux is very much unlike what you expect with a Windows background; the sheer fact that they managed to convince a largely Windows-only shop to let them do it, with an eye to the future, is amazing. I'd have expected to see questions like "why did these guys write the whole fsckin thing, all 100,000 lines of it, and only found out it's not upstreamable now". I've been hearing of AMD trying to get their Linux drivers in good shape for a long time now. "We don't do the thing that is most fundamental to your architecture" looks like the kind of problem that could have surfaced within, I don't know, two emails? Edit: I do think that the LK maintainer was right not to merge this. What bothers me is that everyone's focusing on everything except the examination of the technical issues and what would benefit Linux users.

hashhar 10y ago
I agree with you. We really are a hypocritical bunch. This move may have essentially alienated any new hardware maker from making open source drivers. They too may go the closed source, taped together with a HAL way and that's not good for the long run. This essentially gives a nod to the way Nvidia's been treating Linux.
shakna 10y ago
> I'd have expected to see questions like "why did these guys write the whole fsckin thing, all 100,000 lines of it, and only found out it's not upstreamable now" AMD was told 6 months ago that it wouldn't be merged if they didn't follow certain guidelines. Then they didn't follow the guidelines. What bothers me here, is the way AMD's management has handled the whole thing. It seems like management demanded it be a certain way, and the coders were forced to build something they knew would be unmergable. And then management chucked a hissy fit. There's been really good work here, and management has got upset, rather than follow guidelines, or nVidia's example. It reflects really badly on the company, which is sad considering the space for AMD left by nVidia's Optimus kafuffle. There is a market for GPUs here, but it does need to show some professionalism, which they (management) haven't.
- Waterluvian 10y ago
  You may be right but do you have any evidence? It's too convenient for developers to just blame managers when stupid things happen.
- notalaser 10y ago
  I agree that there is room for disagreement between the two approaches. However, I don't think that AMD did things this way just because of short-sighted management. A HAL-like layer is a solution that I've seen or heard of in a lot of places, from a lot of hardware manufacturers that want to support Linux. It may seem -- and may well be -- a sub-optimal solution, but it's not worse than what we have now, and AMD looks willing to commit to the long-term support of the HAL and the drivers. This is likely something that they want to do not just because they're lazy and would rather spend the money on something else -- it's likely that their management genuinely sees the development and maintenance of an entirely unabstracted set of drivers for Linux as inefficient, especially when you look at how much money they make out of it. And they aren't entirely wrong. Deucher's remark about the Red Hat silo may look malicious and abrasive, but it has a glimpse of truth. I could make a really cool photo album by taking snapshots of developers and managers who are only familiar with Windows and hear about the challenges involved in writing (and upstreaming) a non-trivial Linux driver. I'm not saying that the driver should have been merged as it is just because there's no alternative. I do think, however, that it's a little presumptuous to think its architecture is the way it is just because managers are stupid. Maybe a third option, that's not HAL but also addresses the concerns and requirements of AMD exists.

hashhar 10y ago

I agree with you. We really are a hypocritical bunch. This move may have essentially alienated any new hardware maker from making open source drivers. They too may go the closed source, taped together with a HAL way and that's not good for the long run. This essentially gives a nod to the way Nvidia's been treating Linux.

shakna 10y ago

> I'd have expected to see questions like "why did these guys write the whole fsckin thing, all 100,000 lines of it, and only found out it's not upstreamable now" AMD was told 6 months ago that it wouldn't be merged if they didn't follow certain guidelines. Then they didn't follow the guidelines. What bothers me here, is the way AMD's management has handled the whole thing. It seems like management demanded it be a certain way, and the coders were forced to build something they knew would be unmergable. And then management chucked a hissy fit. There's been really good work here, and management has got upset, rather than follow guidelines, or nVidia's example. It reflects really badly on the company, which is sad considering the space for AMD left by nVidia's Optimus kafuffle. There is a market for GPUs here, but it does need to show some professionalism, which they (management) haven't.

Waterluvian 10y ago
You may be right but do you have any evidence? It's too convenient for developers to just blame managers when stupid things happen.
notalaser 10y ago
I agree that there is room for disagreement between the two approaches. However, I don't think that AMD did things this way just because of short-sighted management. A HAL-like layer is a solution that I've seen or heard of in a lot of places, from a lot of hardware manufacturers that want to support Linux. It may seem -- and may well be -- a sub-optimal solution, but it's not worse than what we have now, and AMD looks willing to commit to the long-term support of the HAL and the drivers. This is likely something that they want to do not just because they're lazy and would rather spend the money on something else -- it's likely that their management genuinely sees the development and maintenance of an entirely unabstracted set of drivers for Linux as inefficient, especially when you look at how much money they make out of it. And they aren't entirely wrong. Deucher's remark about the Red Hat silo may look malicious and abrasive, but it has a glimpse of truth. I could make a really cool photo album by taking snapshots of developers and managers who are only familiar with Windows and hear about the challenges involved in writing (and upstreaming) a non-trivial Linux driver. I'm not saying that the driver should have been merged as it is just because there's no alternative. I do think, however, that it's a little presumptuous to think its architecture is the way it is just because managers are stupid. Maybe a third option, that's not HAL but also addresses the concerns and requirements of AMD exists.