| |||||||||||||
ELC: The embedded Linux nightmareELC: The embedded Linux nightmarePosted Apr 19, 2007 5:01 UTC (Thu) by khim (subscriber, #9252)In reply to: ELC: The embedded Linux nightmare by vmole Parent article: ELC: The embedded Linux nightmare
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.
(Log in to post comments)
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.
|
|||||||||||||