Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

[Grant Likely]

On Fri, 16 May 2014 13:52:42 +0200, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> Hi Grant,
> 
> On Fri, May 16, 2014 at 12:58 PM, Grant Likely
> <grant.likely@xxxxxxxxxxxx> wrote:
> > On Thu, 15 May 2014 09:20:24 +0200, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> >> On Thu, May 15, 2014 at 9:12 AM, Pantelis Antoniou
> >> <pantelis.antoniou@xxxxxxxxxxxx> wrote:
> >> >> We also need to think about kexec. Kexec works by sucking the live tree
> >> >> out of the kernel and creating a .dtb from it to pass to the new kernel.
> >> >> What will the rules be when kexecing? Do all the overlays need to be
> >> >> removed, or does the kernel get the tree with all the overlays applied
> >> >> (in which case none of the overlays can be removed on the other side of
> >> >> kexec).
> >> >
> >> > We can add a sysfs attribute that configures whether overlays are reverted before
> >> > kexec or not. I can't really tell which is the correct option, so let's allow the
> >> > policy up to user-space.
> >>
> >> Kexec'ing into a new kernel doesn't change the hardware, so IMHO the
> >> in-kernel DT should not change.
> >
> > Conceptually though, if overlays are applied then the new kernel has a
> > different tree from the old one. If the overlay is hotpluggable, then
> > after the kexec, the new kernel would no longer be able to unplug the
> > overlay if it uses the current state of the tree instead of pulling the
> > overlays off first.
> 
> Which brings me to another question...
> 
> Why has the overlay system been designed for plugging and unpluging whole
> overlays?
> That means the kernel has to remember the full stack, causing issues with
> e.g. kexec.

Mostly so that drivers don't see any difference in the livetree data
structure. It also means that userspace sees a single representation of
the hardware at any given time.

> Why not allowing the addition of removal of subtrees of the full device
> tree?

Overlays is more than just a subtree. A single overlay can make
manipulations of multiple subtrees that should be handled as logically
atomic.

> This is similar to other hotpluggable subsystems (which are not necessarily
> DT-based), like PCI Express. That way the kernel can pass a
> DT-representation of the actual current device tree to a kexec'ed kernel.

I'm not following you argument. Hardware hotplug systems like PCIe don't
manipulate the firmware data. The kernel detects the new device and
populates the Linux device model directly. Firmware provided data (ACPI
or FDT) isn't involved.

> 
> I missed the initial design discussions, so forgive me if this has been
> beaten to death before.

It's a good question. An alternative would be to keep the overlay tree
as a separate data structure and figure out how to make the core code
reference the overlay when iterating over nodes and properties. I don't
know how complex it would be to do that. We would definitely need to
adjust the data structure a bit, but that isn't an insurmountable
barrier.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/