On Thu, 2015-05-14 at 10:04 +0300, Pantelis Antoniou wrote:
Hmm, since you just want to transmit a whole subtree things are a bit
simpler.
You don’t need any of the fixups, and your target node is known.
So your overlay is simply:
/ {
fragment@0 {
target-path = “/foo”;
__overlay__ {
/* contents of the slot */
};
};
};
I think it’s possible to just bit-mangle a blob (in pseudo code).
const u8 template_overlay_blob[] = { <compiled blob of the above> };
flatten_slot(slot_blob);
overlay_blob = allocate_new_blob(template_overlay_blob, slot_blob);
overlay_node = find_node(overlay_blob, “/fragment@0/__overlay__);
target_prop = find_prop(overlay_blob, “/fragment@0/target-path”);
inject_slot_blob(overlay_blob, overlay_node, slot_blob);
modify_slot_target(overlay_blob, target_prop, slot_target);
I don’t think you need to re-flatten anything, shuffling bits around with
memmove should work.
Fairly gross :-)
But yeah generating the overlay doesn't necessarily scare me, I can
generate a temp tree that is the overlay in which I "copy" the subtree
(or in my internal ptr-based representation I could have a concept of
alias which I follow while flattening).
That leaves me with these problems:
- No support for removing of nodes, so that needs to be added back to
the format and to Linux unless I continue removing by hand in the PCI
hotplug code itself
- No support for "committing" the overlay which needs to be added as
well.
quoted
quoted
quoted
Now we could consider that subtree as a changeset that can be undone,
but that wouldn't work for boot time. And subsequent updates wouldn't
have that concept of "undoing" anyway.
I have posted another patch that does boot-time DT quirk which are
non-revertable.
https://lkml.org/lkml/2015/2/18/258
Not sure how that applies in my case ... I can't change the
representation of the PCI subtree, this is standard OFW representation,
I can't change the FW to make it an overlay-like thing at boot time,
that would break existing kernels.
The idea is to append the ‘quirk’ to the already booting device tree blob.
I know but that's not how things work for me. At boot time the FW passes
me one tree that contains all the PCI stuff it has probed.
Another idea floating around was to simple concatenate the booting blob with
any overlay blobs you want applied at boot time.
Sure but I don't get overlay blobs at boot time.
quoted
quoted
quoted
IE. conceptually, what overlays do today is quite rooted around the idea
of having a fixed "base" DT and some pre-compiled DTB overlays that
get added/removed. The design completely ignore the idea of a FW that
maintains a "live" tree which we want to keep in sync, which is what we
want to do here, or what we could do with a "live" open firmware
implementation.
Now we might be able to reconcile them, but it feels to me that the
overlay/changeset stuff is too rooted in the first concept…
The first DT overlays use case (beaglebone capes) is what got the concept
started.
Right now is a generic mechanism to apply modifications to the kernel
live tree, with the possibility to revert them.
Yes but as I said it's not really thought in term of keeping the kernel
tree in sync with an external dynamically generated tree. Maybe we can
fix it, but it's more complex…
Yes it is, unfortunately.
Right. Which makes the solution of just passing my bit of tree as a blob
which I expand in Linux where I want it rather than an overlay tempting
if we can make Gavin patch more palatable (removing the hybrid stuff
etc...).
Cheers,
Ben.
quoted
Ben.
quoted
quoted
Ben.
Regards
— Pantelis
Regards
— Pantelis
Hi Ben,
On May 14, 2015, at 10:14 , Benjamin Herrenschmidt =
[off-list ref] wrote:
=20
On Thu, 2015-05-14 at 10:04 +0300, Pantelis Antoniou wrote:
=20
quoted
Hmm, since you just want to transmit a whole subtree things are a bit
simpler.
=20
You don=E2=80=99t need any of the fixups, and your target node is =
known.
quoted
=20
So your overlay is simply:
=20
/ {
fragment@0 {
target-path =3D =E2=80=9C/foo=E2=80=9D;
__overlay__ {
/* contents of the slot */
};
};=20
};
=20
I think it=E2=80=99s possible to just bit-mangle a blob (in pseudo =
code).
quoted
=20
const u8 template_overlay_blob[] =3D { <compiled blob of the =
above> };
quoted
=20
flatten_slot(slot_blob);
=20
overlay_blob =3D allocate_new_blob(template_overlay_blob, =
slot_blob);
quoted
=20
overlay_node =3D find_node(overlay_blob, =
=E2=80=9C/fragment@0/__overlay__);
quoted
target_prop =3D find_prop(overlay_blob, =
=E2=80=9C/fragment@0/target-path=E2=80=9D);
quoted
=20
inject_slot_blob(overlay_blob, overlay_node, slot_blob);
modify_slot_target(overlay_blob, target_prop, slot_target);
=09
I don=E2=80=99t think you need to re-flatten anything, shuffling bits =
around with
quoted
memmove should work.
=20
Fairly gross :-)
=20
You don=E2=80=99t want to know how sausages are made, but they are =
delicious :)
But yeah generating the overlay doesn't necessarily scare me, I can
generate a temp tree that is the overlay in which I "copy" the subtree
(or in my internal ptr-based representation I could have a concept of
alias which I follow while flattening).
=20
That leaves me with these problems:
=20
- No support for removing of nodes, so that needs to be added back to
the format and to Linux unless I continue removing by hand in the PCI
hotplug code itself
=20
What kind of nodes/properties you need to remove at _application_ time?
What you describe is inserting a bunch of properties and nodes under
a slot=E2=80=99s device node. Reverting the overlay removes them all =
just fine.
- No support for "committing" the overlay which needs to be added as
well.
=20
That=E2=80=99s the easiest part.
quoted
quoted
quoted
quoted
Now we could consider that subtree as a changeset that can be =
undone,
quoted
quoted
quoted
quoted
but that wouldn't work for boot time. And subsequent updates =
wouldn't
quoted
quoted
quoted
quoted
have that concept of "undoing" anyway.
=20
=20
I have posted another patch that does boot-time DT quirk which are
non-revertable.
=20
https://lkml.org/lkml/2015/2/18/258
=20
Not sure how that applies in my case ... I can't change the
representation of the PCI subtree, this is standard OFW =
representation,
quoted
quoted
I can't change the FW to make it an overlay-like thing at boot time,
that would break existing kernels.
=20
=20
The idea is to append the =E2=80=98quirk=E2=80=99 to the already =
booting device tree blob.
=20
I know but that's not how things work for me. At boot time the FW =
passes
me one tree that contains all the PCI stuff it has probed.
=20
quoted
Another idea floating around was to simple concatenate the booting =
blob with
quoted
any overlay blobs you want applied at boot time.
=20
Sure but I don't get overlay blobs at boot time.
=20
quoted
quoted
quoted
quoted
IE. conceptually, what overlays do today is quite rooted around =
the idea
quoted
quoted
quoted
quoted
of having a fixed "base" DT and some pre-compiled DTB overlays =
that
quoted
quoted
quoted
quoted
get added/removed. The design completely ignore the idea of a FW =
that
quoted
quoted
quoted
quoted
maintains a "live" tree which we want to keep in sync, which is =
what we
quoted
quoted
quoted
quoted
want to do here, or what we could do with a "live" open firmware
implementation.
=20
Now we might be able to reconcile them, but it feels to me that =
the
quoted
quoted
quoted
quoted
overlay/changeset stuff is too rooted in the first concept=E2=80=A6
=20
=20
The first DT overlays use case (beaglebone capes) is what got the =
concept
quoted
quoted
quoted
started.
=20
Right now is a generic mechanism to apply modifications to the =
kernel
quoted
quoted
quoted
live tree, with the possibility to revert them.
=20
Yes but as I said it's not really thought in term of keeping the =
kernel
quoted
quoted
tree in sync with an external dynamically generated tree. Maybe we =
can
quoted
quoted
fix it, but it's more complex=E2=80=A6
=20
=20
Yes it is, unfortunately.
=20
Right. Which makes the solution of just passing my bit of tree as a =
blob
which I expand in Linux where I want it rather than an overlay =
tempting
if we can make Gavin patch more palatable (removing the hybrid stuff
etc=E2=80=A6)
.
=20
I see. Well, how about this?
Who said you have to do the whole blob dance in the firmware?
You can just as easily pass the blob as it is to the linux kernel and
the kernel there can convert it to an overlay and apply it.
Cheers,
Ben.
=20
quoted
quoted
Ben.
=20
quoted
quoted
Ben.
=20
=20
=20
Regards
=20
=E2=80=94 Pantelis
=20
=20
=20
Regards
=20
=E2=80=94 Pantelis
=20
=20
Regards
=E2=80=94 Pantelis