Re: [PATCH] Open Firmware device tree virtual filesystem

[Benjamin Herrenschmidt]

> The biggest problem is the huge collection of workarounds we have
> for PowerPC alone already -- if that can be moved into some
> quirk collection thing, where certain quirks are only run on some
> systems, it might scale.

Well, if you notice, I've been moving most of such workarounds to
prom_init.c, that is, to the code that actually fetches the device-tree
from the firmware, which make things easier.

There are still a few, notably in prom_parse.c, but I'm pretty confident
they aren't too invasive (and I need to backport more fixes from david
there) and in macio_asic, but the later is specific enough to not be a
problem.

> You'll also have to deal with endianness finally (you can *not*
> access an integer property via an int*).

Yes, that's one big thing we'll need to do.

> It will be easiest to start with a biggish collection of hooks,
> that doesn't require too much code change, and slowly converge
> stuff.

Hooks ? How so ?

It's easier to start merging powerpc and sparc I reckon and then, "fix"
that so that it works on x86 :-)

> All properties can be changed, any new property can be created.
> Oh you mean after you killed OF -- yeah, it gets a bit harder
> then eh :-)

You know very well what I meant :-) The ones where it makes sense to
write them back to OF. On machines where OF dies, there are mecanism via
the nvram to store properties in /options (like boot-device etc...),
there are at least 2 such mecanisms (apple oldworld and chrp), and on
machines where OF is still alive, that should probably be an OF call of
some sort.

So we do want some sort of platform hook for -these-, but at the same
time, that's fairly low on the list. Currently, we have no code in the
kernel to deal with that on powerpc, it's all userland via /dev/nvram,
and I reckon it might just stay that way with platform specific userland
tools for a little longer.

Ben.
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/