On Tue, Oct 17, 2017 at 2:20 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote: > On Tue, Oct 17, 2017 at 12:46 PM, Rob Herring <robh@xxxxxxxxxx> wrote: >> On Fri, Oct 13, 2017 at 04:51:03PM -0700, John Stultz wrote: >>> It seems you're suggesting that there be some sort of special overlay >>> partition which users have to flash with pre-built images containing >>> the appropriate overlay dtbs, so that something like the treble >>> overlay-per-partition approach could be used. >> >> I'm not really suggesting anything. I'm not going to take something that >> *only* solves your usecase of apply an overlay embedded in a base dtb >> based on the kernel command line. I have no issue really with either one >> of those. What I don't want is another "overlay manager" for each >> usecase. And sorry, you don't win for being first (you're not really). >> All this I said before. > > So, I'm not actually asking anyone to take anything here, I'm just > trying to reopen the conversation that hasn't gone very far, so we can > find some direction to take. > > I've not followed the discussion super closely here, so apologies if > I'm off base here. But it does seem there's a number of similar > efforts, and it seems no one has gotten enough momentum to make a real > push upstream. It seems its just easier for everyone to keep their own > approach in their own tree and not to bother. At one end, sure, > keeping half baked ideas out of mainline until they really sort > themselves out is fine, but at the other extreme you risk the > half-baked ideas calcifying in their own tree and then you have more > Android (or whatever variant) specific cruft to shake your fist at. > :) > > How do we get to a shared solution here where folks are engaging with upstream? > > Even an "I like approach B, go make that work" would help here. Nudge. Any further thoughts on what sort of an approach might be viable here? thanks -john -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html