Hi, On Mon, May 26, 2014 at 08:14:08AM -0700, Guenter Roeck wrote: > On 05/26/2014 08:09 AM, Sebastian Reichel wrote: > >On Mon, May 26, 2014 at 02:55:37PM +0300, Pantelis Antoniou wrote: > >>On May 26, 2014, at 2:23 PM, Grant Likely wrote: > >>>On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > >>>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. > >> > >>We can support either method. I am not feeling any wiser about which one should be > >>the default TBH, so what about exporting a property and let the platform > >>figure out which is more appropriate? > > > >What about supporting "negative" overlays (so an overlay, that > >removes DT entries)? That way one could reverse apply an overlay. > >All the dependency stuff would basically be the users problem. The > >kernel only checks if it can apply an overlay (and return some error > >code if it can't). This this code is needed anyway to check the > >input from userspace. > > > > Does that mean that I would need to describe such a negative overlay > for each overlay to be able to get it removed ? > > This would introduce an endless source of problems with bad "reverse" > overlay descriptions. Sure, that would "be the users problem", > but I don't think that would make it better. I was thinking about supporting something like "patch --reverse". So you can try to undo the overlay by reverse applying it and you can do it in arbitrary order. Note: The dependency check must be done for all overlays coming from userspace, so that's not a problem __here__. The reverse method can "simply" reverse the overlay patch and apply it like a normal overlay from userspace (and thus using the same dependency checks). -- Sebastian
Attachment:
signature.asc
Description: Digital signature
