Device trees I: Are we having fun yet?

Posted Nov 13, 2013 6:26 UTC (Wed) by olof (subscriber, #11729)
In reply to: Device trees I: Are we having fun yet? by jcm
Parent article: Device trees I: Are we having fun yet?

ACPI and UEFI doesn't magically solve the ARM server problems, and it's troubling that people just walk around that topic thinking it will. They just give you yet another mechanism to communicate the mess that the vendors create.

The x86 space has been more organized because Microsoft forced people to comply with the standard specs (and a product wouldn't ship, plain and simple, if it didn't boot an unmodified Windows install). That's not true for these ARM servers since Linux will be the primary target for many of them -- the same strict requirements aren't there.

On the other hand, maybe, just maybe we can avoid the mess of SMM. It's definitely a mixed blessing to have (or require) that level of under-the-covers workaround for compliance, since we all know just how messy and buggy firmware can be. On the other hand, it avoids the same mess to crawl into the kernel.

Device trees I: Are we having fun yet?

Posted Nov 13, 2013 6:57 UTC (Wed) by jcm (subscriber, #18262) [Link] (1 responses)

Olof, I agree that ACPI doesn't magically solve the problems. But what I mean is, I expect to see such platform standardization in the ARM server space. I would be /very/ surprised if there aren't movements in that regard. As far as SMM, sadly I raised this 3 years ago that I thought vendors would abuse TrustZone (and in particular create their own apps running on the TEE) to emulate SMM on AArch64, and that's roughly what I see happening. I've made recommendations to mitigate the impact, which I see being lesser because: a). You don't stop all CPUs in the system. b). Most of this crap can be handled by management cores in the designs that I have reviewed so far.

Device trees I: Are we having fun yet?

Posted Nov 13, 2013 7:39 UTC (Wed) by olof (subscriber, #11729) [Link]

Oh, I have hope that the vendors that have had enough planning to involve you in their designs will come out with something fairly sane, even though some of the recent patch sets can introduce a good amount of doubt.

My greater concern is the second-tier vendors, or the mass-market vendors that will do the bare minimum (and not quite know what they're doing, or at least not seeing the bigger picture), etc. It'll take quite a bit of education of them to sort things out right, and it only takes a few of them going to market anyway to make the kernel side of thing very interesting and possibly messy. It'll be interesting to see how it plays out.

Device trees I: Are we having fun yet?

Posted Nov 14, 2013 9:23 UTC (Thu) by deepfire (guest, #26138) [Link] (3 responses)

> The x86 space has been more organized because Microsoft forced people to
> comply with the standard specs (and a product wouldn't ship, plain and
> simple, if it didn't boot an unmodified Windows install).

I find "boot an unmodified Windows install" being a rather weak substitute for standards compliance.

Device trees I: Are we having fun yet?

Posted Nov 14, 2013 14:24 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

Well it isn't just being able to boot, MS has pushed for several device standards such as for webcams so they didn't have to deal with buggy crashy vendor drivers making them look bad.

Device trees I: Are we having fun yet?

Posted Nov 26, 2013 17:18 UTC (Tue) by nye (subscriber, #51576) [Link]

On a related note, anyone know why there's no such thing as a standardised ethernet class driver?

Device trees I: Are we having fun yet?

Posted Nov 15, 2013 17:52 UTC (Fri) by drag (guest, #31333) [Link]

> I find "boot an unmodified Windows install" being a rather weak substitute for standards compliance.

Yet it's the most effective standards compliance mechanism that has ever existed as far as hardware goes.