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.
YOu don't need to *stop* the other CPUs, you just need to
prevent them from entering the client interface. Put a lock
in front.
That's not the issue.
If the global OFW lock disables interrupts,
Why would it?
other cpus trying to get
that lock can't receive CPU cross calls since they are delivered via
interrupts, get it? That's the issue you need to be careful about.
Yes I "get it", thank you. I don't see it as an insurmountable
problem though, even if it exists at all.
Okay -- so answer the second part of my concern please: if you keep
a copy, you need to keep both in sync -- that means every change
by the kernel has to be done twice, and you won't ever be told about
changes by the OF, so you have to get a full fresh copy every single
time you return from an OF client call that could have changed a
property.
Sure, you need to call OFW when a property is changed, and we have
code to handle that perfectly fine in the sparc of_*() code.
There are mechanisms on the OFW implementations that do hot plugging
to learn about the OFW tree changes. On some sparc64 platforms,
for example, you have to do a "SUNW,foo-operation" OFW call when a
board is hot-plugged in an Ex000 enterprise box, and after that call
finishes successfully, you know where the new board is in the OFW
tree so you import everything underneath. You do the opposite for
a hot-unplug sequence.
Every platform is going to handle this differently.
Yes.
But there is nothing about it that precludes doing an in-kernel
OFW tree.
Nothing _precludes_ doing that of course. And it is good
to have an in-kernel tree obviously, you pretty much need
one to make the connection between the OF device tree and
the kernel notion of devices. I'm just saying that you
shouldn't consider the kernel copy the "master", unless of
course you killed OF.
Even the most brute-force implementation is possible. When any
hot-plug event occurs, validate the current in-kernel tree. It's that
easy.
On more events than just hot-plug, but yes. Now consider the
consequences: no part of the kernel can hang on to a reference
to a property, or a device node, while any such event can happen
(at least if it requires the data in there to still be valid ;-) )
This means that anything that uses the device tree always should
go over some accessor functions and get all the info they need
at once, not wait until later.
I guess it's good to have someone like you, the dissenter in the
group, but Ben and I will snuff you out completely soon enough :-)))
Heh. I guess I look at the problem more from the OF side, and
you more from the SPARC kernel side, and Ben of course more from
the PowerPC kernel side. That doesn't make me a "dissenter", we
all have (mostly) the same goal in the end.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
