| |||||||||||||
ELC: The embedded Linux nightmareELC: The embedded Linux nightmarePosted Apr 18, 2007 12:35 UTC (Wed) by khim (subscriber, #9252)In reply to: ELC: The embedded Linux nightmare by gouyou Parent article: ELC: The embedded Linux nightmare
You can keep old version on your server, but active distribution development always goes in "unstable/testing" branch (where latest and greatest stuff lives). Embedded developers worry about a lot of things and like to develop in stable branch. Then, few years down the road, they try to switch from 2.6.10 to 2.6.20 (or something like this) when it's clear that they actually need to switch. But linux kernel is not designed to be used this way! Either you change your driver over time while tracking changes in kernel - or you need MAJOR overhaul when you need to switch. Nobody is trying to keep things compatible and reduce amount of changes needed low! And this is when things are going straight to hell: embedded developers blame linux kernel developers (why the hell they change internals so much?) and linux kernel developers blame embedded developers (you were asked year ago if you still need devfs or not - there were no complains, why you are whining NOW?).
(Log in to post comments)
ELC: The embedded Linux nightmare Posted Apr 18, 2007 20:43 UTC (Wed) by vmole (guest, #111) [Link] Either you change your driver over time while tracking changes in kernel - or you need MAJOR overhaul when you need to switch. Or, you get your driver *into* the standard kernel, and let the main kernel developers keep it up to date with respect to kernel changes, so that all you have to worry about is fixes specific to your device, many of which will *also* be provided by the kernel community.
ELC: The embedded Linux nightmare Posted Apr 18, 2007 22:34 UTC (Wed) by bronson (subscriber, #4806) [Link] Then they say, "But... give up control of my code? Do you have the brain worms??"
The Cirrus reply mentioned in the article had this attitude. Companies seem to believe that, unless their engineers are the sole committers, their driver will turn into, I don't know, Paris Hilton or something. They won't let "their" source code be modified by the more skilled and qualified Linux kernel team, even though it produces a fairly significant cost savings for them.
It's bizarre. I hope this attitude is just a hold-over from the proprietary 90s and disappears as the new generation of programmers takes over.
ELC: The embedded Linux nightmare Posted Apr 19, 2007 3:02 UTC (Thu) by markcox (guest, #29577) [Link] It's bizarre, how people engaging in a seemingly 'civilized' discussion resort to making negative remarks about celebrities to make their point. Is this lwn or digg.com ?
ELC: The embedded Linux nightmare Posted Apr 19, 2007 7:21 UTC (Thu) by Zenith (subscriber, #24899) [Link] It's bizarre, how people engaging in a seemingly 'civilized' discussion resort to making negative remarks about celebrities to make their point. Is this lwn or digg.comI actually found the comment quite funny. Why should we always keep the discussion insanely clean and to the point? Even programmers need to laugh once in a while, and I did :) And really, do you think that Paris Hilton cares much for what programmers have to say about her? ;)
ELC: The embedded Linux nightmare Posted Apr 21, 2007 21:39 UTC (Sat) by bronson (subscriber, #4806) [Link] Sorry markcox, I did not intend to offend. Allow me to rephrase...
They're afraid "their driver will turn into, I don't know, a frothing cow or something."
Is that easier on your sensibilities?
ELC: The embedded Linux nightmare Posted Apr 22, 2007 0:49 UTC (Sun) by markcox (guest, #29577) [Link] haha. Yes much better thanks :)
ELC: The embedded Linux nightmare Posted May 2, 2007 7:57 UTC (Wed) by blujay (guest, #39961) [Link] Does this mean that you equate Paris Hilton to a frothing cow?
For the record, I quite enjoyed the original, along with the brain worms. =)
ELC: The embedded Linux nightmare Posted May 1, 2007 18:19 UTC (Tue) by ParisHilton (guest, #45014) [Link] Yes, I find this statement offensive! I've been a dedicated LWN reader for years and I've never been so insulted!
ELC: The embedded Linux nightmare Posted Apr 19, 2007 8:17 UTC (Thu) by nix (subscriber, #2304) [Link] The companies' developers obviously don't believe that, or given theoverwhelming male-dominance of the software development field, they'd all be *rushing* to hurl all their code at the kernel devs.
;}
ELC: The embedded Linux nightmare Posted Apr 19, 2007 5:01 UTC (Thu) by khim (subscriber, #9252) [Link] Or, you get your driver *into* the standard kernel, and let the main kernel developers keep it up to date with respect to kernel changes, so that all you have to worry about is fixes specific to your device, many of which will *also* be provided by the kernel community. Not in the books, I afraid. Main kernel developers will probably not accept non-working driver for non-working hardware in main kernel and for embedded developers time where driver work and hardware is available is endpoint: it exist, it works, what else will you need ? Any sane PHB will stop development at this point: it's time to produce and sell the gadget, not bother will useless "mainstream integration"! Engineer can be used for some other products... Yes, few years down the road (when time to upgrade base version of kernel will come) this approach will prove troublesome, but to understand that you need to look few years down the road - rare for PHB.
ELC: The embedded Linux nightmare Posted Apr 19, 2007 7:06 UTC (Thu) by net_bh (guest, #28735) [Link] Any sane PHB will stop development at this point: it's time to produce and sell the gadget, not bother will useless "mainstream integration"! Engineer can be used for some other products...It is hard to believe that embedded developers are doing one-off gadgets _all the time_. In my experience, there is usually a product line, a few products on a common platform and most drivers can be carried forward across the product line with few changes. And even across SoC platform generations, a surprising amount of code can be reused. So merging with mainline does help. And even if you are doing one-off gadgets, mainlining today ensures that 5 years down the line when you want to do an update on the gadget, your code has been maintained for free in the latest mainline kernel. Yes, few years down the road (when time to upgrade base version of kernel will come) this approach will prove troublesome, but to understand that you need to look few years down the road - rare for PHB. I have good PHBs then. It is our policy that as soon the product is released, we start merging the code back into upstream/mainline, etc. So at any time, we deal with a very minimal (mostly non-existent) diff with mainline.
ELC: The embedded Linux nightmare Posted Apr 19, 2007 21:41 UTC (Thu) by drag (subscriber, #31333) [Link] The way it sounds to me is that embedded developers are simply very used to having to rewrite everything all the time.
That's what they expect, that's what they do. So they make sure to do it as quick and dirty as possible and move onto the next project. Minimal time invested, minimal effort wasted.
In contrast the Kernel developers, in order to work most effectively, are tryhing to enforce a development methodology on these people. Effectively the Linux developers are telling them that instead of quick and dirty and get finished as soon as possible.. they should go quick and clean and never ever stop developing.
Culture clash.
ELC: The embedded Linux nightmare Posted Apr 20, 2007 14:03 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link] I have good PHBs then.Oxymoron. It means that your Bs aren't PH.
ELC: The embedded Linux nightmare Posted Apr 20, 2007 14:54 UTC (Fri) by sepreece (subscriber, #19270) [Link] "In my experience, there is usually a product line, a few products on a common platform and most drivers can be carried forward across the product line with few changes."
Yes, but the OS version used for the platform is typically not changed over the life of the product line (or changed only at very long intervals), so there's usually no need to maintain the drivers over that period except for hardware or feature tweaks, which would have to be done separately anyway.
That said, it would make sense to push the drivers to mainstream anyway, for the usual benefit of community review. The problem in doing that is that by the time the first product is ready to ship the kernel version is not current and bringing the drivers up to current would be added work that would be hard to justify just by the possibility of finding bugs that haven't already manifested. [In many cases the drivers can't be posted prior to shipment because they would expose product details that we want to keep secret as long as possible for competitive reasons.]
I think we're going to get better at this, over time, but it's a learning process. Thomas's advice was useful; I just thought his talk was a little one-sided.
|
|||||||||||||