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

From: Grant Likely
Date: Mon May 26 2014 - 07:24:09 EST


On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> Hi Grant,
>
> On Mon, May 26, 2014 at 12:48 PM, Grant Likely
> <grant.likely@xxxxxxxxxxxx> wrote:
> > On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> >> On Tue, May 20, 2014 at 7:50 AM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
> >> >> 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.
> >>
> >> Sorry, I don't follow the argument about the "single representation of the
> >> hardware".
> >
> > Er, s/of the hardware/of the tree/. Right now the overlay design
> > modifies the live tree which at the same time modifies the tree
> > representation in /sys/firmware/devicetree. If the design was changed to
> > keep the overlay logically separate, then I would think we want to
> > expose that information to usespace also. In fact, I think we would need
> > to for usecases like kexec.
>
> OK, so it does modify the real tree, and doesn't keep the actual overlays.
>
> I was under the impression the overlay stack was also kept in memory, to allow
> reversal, so there was a misunderstanding.
>
> Hence for kexec, the tree in /sys/firmware/devicetree can just be passed
> to the new kernel, as that's the current representation of the hardware?

Heeheehee. We're back where we started. The original question is whether
or not that is a valid approach. If the overlay represents something
that can be hot plugged/unplugged, then passing it through to the second
kernel would be the wrong thing to do. If it was a permenant addition,
then it probably doesn't need to be removed.

We do actually keep the overlay info in memory for the purpose of
removal exactly so we can support hot unbinding of devices and drivers
that make use of overlays.

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/