[PATCH] Open Firmware device tree virtual filesystem

[David Miller]

From: Segher Boessenkool <segher at kernel.crashing.org>
Date: Tue, 2 Jan 2007 22:28:21 +0100

> >> Not single thread -- but a "global OF lock" yes.  Not that
> >> it matters too much, (almost) all property accesses are init
> >> time anyway (which is effectively single threaded).
> >
> > Not that true anymore. A lot of driver probe is being threaded 
> > nowadays,
> > either bcs of the new multithread probing bits, or because they get
> > loaded by userland from some initramfs etc..
> 
> The kernel doesn't care if one CPU is in OF land while the others
> are doing other stuff -- well you have to make sure the OF won't
> try to use a hardware device at the same time as the kernel, true.

True, but at the very least you have to prevent multiple cpus
from enterring OFW.  In fact this is very important.

OFW is not multi-threaded therefore you can't let multiple CPUs call
into OFW at one time.  You must use some kind of locking mechanism,
and that locking mechanism is not simple because it has to not just
stop the other cpus, it has to be able to stop the other cpus yet
still allow them to receive SMP cross-calls from the firmware if the
OFW call is 'stop' or similar.

> I'm a bit concerned about the 100kB or so of data duplication
> (on a *quite big* device tree), and the extra code you need
> (all changes have to be done to both tree copies).  Maybe
> I shouldn't be worried; still, it's obviously not a great
> idea to *require* any arch to get and keep a full copy of
> the tree -- it's wasteful and unnecessary.

The largest amount of memory I've ever seen consumed on sparc64
was 76K and this is 1) 64-bit and 2) an ENORMOUS machine with
lots of cpus and devices.  And I know because sparc64 prints
a kernel message at boot which states how much memory was
consumed by the in-kernel device tree copy.

That ENORMOUS machine also had a lot of ram.

76K, that's just over 8 FREAKIN PAGES.  It's nothing!

I think all this worry is overblown, terribly so in fact.

Please let's get over this memory consumption non-issue and move
on to more productive talk.