Messages in this thread | | | From | Segher Boessenkool <> | Subject | Re: [PATCH] Open Firmware device tree virtual filesystem | 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.
>>> Finally, you can't have something as simple as powerpc's >>> get_property() >>> (that just returns a pointer to the property content) with direct OF >>> access unless you use some magic static buffer or some crap around >>> those >>> lines, or add passing of a buffer in, so from a driver pointer of >>> view, >>> the interface provided by powerpc/sparc is nicer. >> >> But since you have a _put() function anyway, for your reference >> counting, having magic (automatically allocated, not static of >> course) buffers works just fine. > > You can maybe create an in-memory cache of all properties in a node > from > whatever function that returns a node pointer and dispose of them on > _put(), that would allow to keep the get_property semantics as-is with > a > "live" tree, but I still don't see the point
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.
Segher
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |