LWN: Comments on "KS2009: Generic device trees"

KS2009: Generic device trees

johill — Wed, 04 Nov 2009 10:18:45 +0000

Eh? I hate to say it, but your comment reads a lot like FUD.

First of all, I think you're confused about how the DT bindings are created -- there's no "committee" or "outside 'experts'" involved. Yes, there's peer review of bindings, but from what I've seen it's been mostly technical.

Then, you're ignoring the fact that DTs work very well for a large number of boards. Yes, there will be new types of devices that need new drivers ... invariably, boards don't just get faster! But they still include a plethora of standard devices. Serial ports, RAM, IRQ routing, PCI(e) busses, etc. None of that is usually re-architected every time a new board is created, that would be way too expensive!

As a result DTs can (and in practice do, I've seen it done) solve a large percentage of a new board port, up to 100%.

KS2009: Generic device trees

HalfMoon — Wed, 04 Nov 2009 10:00:45 +0000

Those trees are a way to communicate standard information. But embedded boards have little of that. They're heavy on the customization, the one-off, the new-in-this-revision stuff.

See, that's the reason these "trees" don't work so well. Hardware is very customizable. New chips come out all the time and they need a lot more information. This one has a dozen pins for random uses that drivers need to understand about, or in some cases board setup code. Three other variants of the chip have *different* uses for those pins, and need very different configuration. NOT STANDARD. Gotta come up with some way to cram it into the device tree. Committee negotiations slow that process down. Multiply that by, say, six instances of that problem on your new board that's got to enter testing next quarter...

And when you get to the point where some "device tree" can solve that ... you're really just growing chip-specific customizations, which still require C code to handle. At that point, there's no benefit to having to come up with some board or chip specific declarations in the "device" tree and then come up with corresponding C code. Easier to just have the C code to cope with, and to do it without needing to involve outside "experts" who have their own ideas about how your hardware should work, and don't have your own product timetables (or success) as priorities. Who may want some fancy Architecting before they add new mechanisms...

The reason some folk like that stuff is that when you can use it, you're starting with a simple problem. That's why there's a time saving: they're both derived from having simple hardware. But a LOT of hardware is nowhere near simple — or regular! — enough to use that approach.

KS2009: Generic device trees

roelofs — Wed, 28 Oct 2009 20:11:39 +0000

btw, "You're putting Descartes before a gift horse so he can look in its mouth" deserves some sort of award.

The "Quip with Existential Mixed-metaphor Undertones" Award?

:-)

KS2009: Generic device trees

nix — Sat, 24 Oct 2009 20:06:12 +0000

Aha. I see. (Not that I was really 'objecting', it was less strenous than
that.)

btw, "You're putting Descartes before a gift horse so he can look in its
mouth" deserves some sort of award.

KS2009: Generic device trees

landley — Sat, 24 Oct 2009 19:16:27 +0000

You're putting Descartes before a gift horse so he can look in its mouth.

The lack of a device tree has made emulating new boards extremely fiddly. A board is essentially a collection of devices. So the lack of variety in hardware peripheral emulation is a _symptom_ of what I'm talking about. Bringing up the symptom as an objection to the proposed solution seems weird to me.

You've missed the point at a more fundamental level: QEMU currently isn't about kernels, it's about userspace. It has "a hard drive", "a network card", "a sound card", and so on. Doesn't currently matter which, they're just there to do a job by connecting the emulated environment to the host. They're not there to regression test your drivers.

Once you've booted into a working userspace, you can run (even natively build) a PPC version of arbitrary packages on a standard laptop. A developer can regression test their software on various different targets from a cron job or from a coffee shop, without needing to drag a half-dozen different hardware boxes around.

And you can point an upstream package maintainer at a tarball like http://impactlinux.com/code/firmware/downloads/binaries/s... and tell them: download that, extract it, execute the "./run-emulator.sh" script, cd /home, wget your source tarball from the internet and build it in there, and then do THIS to reproduce the problem I'm seeing on arm. (The fact they didn't have an arm environment in which to reproduce the problem? No longer an issue, here's one that runs under qemu.)

That's useful today.

Adding device tree support would make it useful in additional contexts, able to more closely emulate a wider range of boards out there. Then it could _start_ being a good thing to regression test kernels against, at some point in the future.

Rob

KS2009: Generic device trees

nix — Sat, 24 Oct 2009 11:24:58 +0000

Yeah, theoretically. If QEMU's emulated hardware wasn't a very limited
selection of antiquated stuff then this might be useful :))

(well, with virtualization hardware now allowing one VM to gain dedicated
access to one hardware device, QEMU could use the core kernel's driver for
that device: the device tree thing might be useful there. But I'm not
really sure how common that is. SR-IOV might make it actually useful even
if you run more than one VM at once :) )

KS2009: Generic device trees

landley — Sat, 24 Oct 2009 05:13:14 +0000

It also potentially makes life for QEMU, which can take a flattened device tree and parse it to know what emulated hardware to _provide_, and then the built in bootloader (the -kernel option) can feed that device tree on to the kernel.

KS2009: Generic device trees

klossner — Mon, 19 Oct 2009 21:42:00 +0000

Device trees are an attempt to move that information out of the code and into a separate data structure.

More to the point, device trees are a standard way for the boot code to communicate platform configuration to the kernel. For example, the kernel needs to be told how much RAM exists. The device tree replaces a hodgepodge of ad hoc "boot records," "BIOS information structures," and hyper-extensions of the kernel cmdline.