| |||||||||||||
"We want more drivers, no matter how 'obscure' [...]""We want more drivers, no matter how 'obscure' [...]"Posted Apr 19, 2007 16:42 UTC (Thu) by GreyWizard (guest, #1026)In reply to: ELC: The embedded Linux nightmare by sepreece Parent article: ELC: The embedded Linux nightmare
[...] devices are generally expected to remain the same from the day they are shipped to the day they are discarded. Did I miss the part where Gleixner advocates forcing users to upgrade the firmware on their mobile phones at gunpoint? Working with and contributing to the community doesn't force anyone to change firmware on devices that have already shipped. The point is that this is not evil on the vendor's part, [...] As far as I can see Gleixner attributes the problem to hubris and ignorance, not evil. When [the vendors] find a bug or make an enhancement, their base is so far from the community's that the community has no interest in what they have to say. Being so far from the community's sources is an unmistakable sign of a serious software design mistake. There's no way these vendors know more about integrating kernel features than Gleixner and the rest of the kernel community. But they are often working on things that literally nobody else in the world cares about (like devices for custom hardware) [...]
(Log in to post comments)
"We want more drivers, no matter how 'obscure' [...]" Posted Apr 20, 2007 1:45 UTC (Fri) by sepreece (subscriber, #19270) [Link] Gosh, you put a more negative spin on what I said than I intended. I enjoyed Thomas's talk (and the chat we had this afternoon) and agree with many of his points. I plan to take some of his suggestions back to work to see if I can sell them.
I'm not sure I consider "hubris and ignorance" a lot nicer to be called than evil; at least evil implies you're doing it on purpose and with awareness. I don't believe he suggested any such thing, just that we were missing an opportunity and could gain by working differently. We're not ignorant of the choice, we have just chosen differently. We don't think we know more than Thomas, except perhaps about the specifics of our business and our needs.
Being far from the current version is just a business choice, not a design failure. We build platforms that last five years or more with only tweaks in the components, rather than replacements. It's hard to argue that this should be done differently. Version shifts are typically done at the next major rev of the platform, but bugs are found over the whole life of the platform.
"We want more drivers, no matter how 'obscure' [...]" Posted Apr 20, 2007 15:50 UTC (Fri) by GreyWizard (guest, #1026) [Link] I don't believe he suggested any such thing, just that we were missing an opportunity and could gain by working differently. He certainly phrased it more tactfully than I did, but people usually miss opportunities either because they don't know about them (ignorance) or because they think they know better and are mistaken (hubris). Being far from the current version is just a business choice, not a design failure. By this reasoning every design decision is actually a business choice and there is no such thing as a design mistake. We build platforms that last five years or more with only tweaks in the components, rather than replacements. It's hard to argue that this should be done differently. Perhaps that's why no one is arguing that. Gleixner seems to be arguing that the particular way vendors attempt to reach that goal is flawed, not that the goal itself is a problem. Version shifts are typically done at the next major rev of the platform, but bugs are found over the whole life of the platform. No device vendor needs to change 10,000 kernel files just to have bug fixes relevant to their devices when a complete operating system distribution for general purpose computers changes only 8,000. As Gleixner says, the reasons vendors give for use of special, closed, vendor kernels don't hold water.
"We want more drivers, no matter how 'obscure' [...]" Posted Apr 20, 2007 21:56 UTC (Fri) by filker0 (guest, #31278) [Link] I worked on a project as a contractor that used a kernel 2.6.10 distribution obtained through Timesys on a PPC440GX. Because of the process at the company the work was done for, and the industry standards at work, we ended up unable to change the kernel version as new kernels came out as we would have had to start from scratch on the approval process for the kernel for each upgrade. The kernel release will never change for the life of the product, though it may be patched, and the application software updated. There is only one customer for the product. The hardware is unique to the platform, and any new version of the platform will use different hardware that would not be compatible with the drivers.
Because of the above, it was decided not to attempt to mainstream the drivers that we wrote. Having the community maintain the drivers for us would be nice, but how is anyone going to test them without the custom ASICs and FPGAs that they control?
I believe that it is for reasons like the above that many embedded developers don't try to put their stuff back in the kernel -- they end up using out-of-date kernel versions, they don't update the kernel version for the life of the product, and the hardware is custom and unique to the particular "box".
"We want more drivers, no matter how 'obscure' [...]" Posted Apr 21, 2007 12:52 UTC (Sat) by farnz (guest, #17727) [Link] And, unfortunately, your employer missed the gain from mainstreaming the drivers. The community obviously can't test the drivers for you, but there have been changes to the kernel that might result in your drivers needing janitorial-grade changes (the change of the argument list for interrupt handlers, as one example - LWN maintains a list of changes). These changes will be made by the community for you if the driver is mainstreamed.While the changes will only be compile tested, if your employer decides to make the jump from 2.6.10 to 2.6.20 (for example), they'll find that the drivers at least compile, and don't break the kernel. This reduces the porting load; instead of having to find out what's changed, update your drivers, get them building, test them and debug them, you're down to just testing the drivers, and debugging them as needeed. Further, you can use git to look at what's been done to your drivers, and thus have a good chance of spotting cases where someone's misunderstood what the hardware does as they clean up the drive. It's a difficult way of thinking to come to from a proprietary world; what other "upstreams" will maintain code they cannot test in a building and theoretically working fashion?
|
|||||||||||||