KS2010: Development process [LWN.net]

KS2010: Development process

Posted Nov 4, 2010 11:00 UTC (Thu) by Klavs (guest, #10563)
In reply to: KS2010: Development process by swetland
Parent article: KS2010: Development process

I'm a bit confused here. You seem to be against BOTH devicetrees and discoverable buses? and if so - what solution do you think is the best for embedded environment?

to post comments

KS2010: Development process

Posted Nov 4, 2010 12:01 UTC (Thu) by swetland (guest, #63414) [Link] (1 responses)

I love nice enumerable busses -- I just almost never have the luxury of them existing on the embedded platforms I work with. In their absence, I find the existing board/machine file mechanism Linux uses gets the job done and without having to depend on fragile links between data structures embedded in the bootloader or elsewhere and the kernel.

I'd be happy to see improvements to make it easier to maintain board files and such -- they can get a little unwieldy -- but I'm not convinced that a device tree approach actually improves the situation.

I've never worked on a production device (typically shipping between hundreds of thousands and millions of units) where having to compile a new kernel to pick up device-specific hardware support is the major pain point. Certainly I never have a canned, existing kernel that I'm going to just use with no modifications -- power tuning and debugging during stabilization guarantees that we're going to be spinning quite a few kernel builds until things are ready to ship.

KS2010: Development process

Posted Nov 4, 2010 16:41 UTC (Thu) by dlang (guest, #313) [Link]

nobody is expecting that device trees will eliminate the need for you to compile your own kernel for a production system.

it's also not that you will take a kernel compiled for one device and change the devicetree file and load it on another device.

what they will do is make it so that there aren't 70 different subarchitectures in ARM that all have to be tested individually and replace it with a much smaller number with devicetrees identifying the minor details like where a particular piece of hardware is addressed. As such it will make it easier for people to maintain the kernel and make sure that it will work.