On Thu, 2015-05-14 at 10:34 +0300, Pantelis Antoniou wrote:
quoted
quoted
What you describe is inserting a bunch of properties and nodes under
a slot’s device node. Reverting the overlay removes them all just fine.
Except that still doesn't work for boot time :-)
So I would have to do a special case on unplug:
if (slot->dt_is_overlay) /* set to false at boot */
remove_subtree_myself();
else
undo_overlay(slot->overlay);
OK, in that case you do require removal. But in any case it’s the ‘negative’
of an already applied one, either at boot time or not.
Sort-of, unless we have a way in the overlay to simply specify node
removal statements so we don't have to explicitly remove all properties
(or even all children).
Modifying the overlay code to apply a ‘negative’ property should do the trick.
Is that correct?
I would do negatives node and let Linux imply the properties (or even
children).
But yes, that would probably do.
.../...
I will probably need that generation count myself for my PCI use case.
quoted
However that requires supporting removal of nodes/properties. So I'm
tempted to keep that feature on the back burner and go with an ad-hoc
interface for PCI for now.
I see. Bonne chance :)
Merci :)
Cheers,
Ben.
Hi Ben,
On May 14, 2015, at 10:47 , Benjamin Herrenschmidt =
[off-list ref] wrote:
=20
[snip]
So I spend some time thinking about your use case and I think it boils =
down
to this:
I have a live tree in the firmware, I have made changes and I need to =
reflect
those changes to the live tree in the kernel.
Sounds like =E2=80=98how do I generate a patch for getting those two in =
sync'. No?
I can see where this might be useful for others as all.
I think we really need to create a liblivedt like we have libfdt since
we have a number of projects going about using/manipulating DT at =
runtime.
1. The linux kernel, with it=E2=80=99s own live tree implementation.
2. The device tree compiler (it has a live tree) custom implemented.
3. Your weird and wonderful (or wacky) firmware.
4. u-boot does use DT now, but it does with libfdt. I believe this is =
suboptimal.
5. barebox does DT as well.
Most of what we want to do with DT can be abstracted in a library I =
think that
all of those projects can use.
What are your thoughts?
Regards
=E2=80=94 Pantelis
On Thu, 2015-05-14 at 14:02 +0300, Pantelis Antoniou wrote:
Hi Ben,
quoted
On May 14, 2015, at 10:47 , Benjamin Herrenschmidt [off-list ref] wrote:
[snip]
So I spend some time thinking about your use case and I think it boils down
to this:
I have a live tree in the firmware, I have made changes and I need to reflect
those changes to the live tree in the kernel.
Sounds like ‘how do I generate a patch for getting those two in sync'. No?
More or less.
I can see where this might be useful for others as all.
I think we really need to create a liblivedt like we have libfdt since
we have a number of projects going about using/manipulating DT at runtime.
1. The linux kernel, with it’s own live tree implementation.
2. The device tree compiler (it has a live tree) custom implemented.
3. Your weird and wonderful (or wacky) firmware.
4. u-boot does use DT now, but it does with libfdt. I believe this is suboptimal.
5. barebox does DT as well.
Most of what we want to do with DT can be abstracted in a library I think that
all of those projects can use.
What are your thoughts?
Well, we have at least two implementations, the kernel one and the one
in our OPAL firmware:
https://github.com/open-power/skiboot/blob/master/include/device.h
https://github.com/open-power/skiboot/blob/master/core/device.c
The latter uses some nice Rusty tricks (tm) for multiple argument
functions.
It would make sense to do a library somewhere yes. However, I need to
cut my firmware API pretty much today so I think for now I'll stick
to something Ad-Hoc for the PCI hotplug code that just passes the
bit of FDT with the new devices and leave the "grand project" of live
sync of the tree for later.
There are other implementations of live DT in various Open Firmware
variants out there, most are in Forth which I suggest you don't bother
with unless you enjoy pain, but I think at least one of these is
actually in C.
Cheers,
Ben.