Messages in this thread | | | Date | Mon, 6 May 2013 16:25:07 +0100 | Subject | Re: device tree not the answer in the ARM world | From | Luke Kenneth Casson Leighton <> |
| |
mark, thank for this. i'm bringing lkml back in [my decision] but just this once as i believe the point's now been made. i'm also leaving it below [top-post style] as it's background, as well as standing on its own merit.
i was under the impression that device tree had been declared successful on power-pc [and wasn't aware of SPARC], so a reality check is much appreciated. in effect what you're saying is that the standardisation through things *other* than device tree - i.e. there wasn't so much of a problem of diversity in the first place [*1], and this in turn means that device tree could be declared "more" successful.
in other words, once again, the link between the original purpose for which device tree was invented [solve the ARM hardware diversity / proliferation problem] and its actual success in achieving that purpose is demonstrated to be at best an assumption and at worst a failure [in the ARM world].
that there are *other* successes - incidental to its genesis - that device tree has solved is fantastic, but completely beside the point.
so the question becomes - unless someone can demonstrate that device tree has or can solve the [ARM hardware diversification] problem and nobody has so far - what *can* solve the problem of massive hardware diversity [both SoCs and peripherals] in the face of pathological corporate behaviour that i've outlined over the course of the past few messages?
l.
[*1] for many reasons - not least but most obviously as mark clearly points out: there aren't that many peripherals to support!!!
On Mon, May 6, 2013 at 3:06 PM, Mark Morgan Lloyd <markMLl.debian-arm@telemetry.co.uk> wrote:
> [Grimace] DeviceTree works up to a point on SPARC and PPC Macs, where there > is a limited number of peripheral device types and (in general) they're > described by published data. Part of that success though is because these > machines also expose a standardised UI (OpenPROM or whatever you want to > call it) which developers can use for manual enumeration and debugging and > which the kernel can use provided that it gets the calling convention right > (I've seen a firmware change on SPARC break the kernel). > > Leaving aside the more esoteric peripherals (sending morse using a camera > flash LED or whatever :-) there are at least t^Hfour problems: > > i) There's no standardised interface to get at the configuration. > > ii) It's not self-describing, particularly in the case of GPIO-attached > peripherals. > > iii) It's no replacement for enumerating PCI-attached peripherals. > > iv) It's no replacement for enumerating chips on a JTAG loop. > > Put another way, Cory Doctorow's "InstallParty" software isn't even science > fiction: it's pure fantasy, and is likely to stay that way. > > -- > Mark Morgan Lloyd > markMLl .AT. telemetry.co .DOT. uk > > [Opinions above are the author's, not those of his employers or colleagues] > > > -- > To UNSUBSCRIBE, email to debian-arm-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmaster@lists.debian.org > Archive: http://lists.debian.org/km8de1$mel$1@pye-srv-01.telemetry.co.uk >
| |