| |||||||||||||
"We want more drivers, no matter how 'obscure' [...]""We want more drivers, no matter how 'obscure' [...]"Posted Apr 20, 2007 21:56 UTC (Fri) by filker0 (guest, #31278)In reply to: "We want more drivers, no matter how 'obscure' [...]" by GreyWizard Parent article: ELC: The embedded Linux nightmare
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".
(Log in to post comments)
"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?
|
|||||||||||||