Re: Moving ARM dts files

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3061 bytes --]

On Tue, Dec 04, 2018 at 10:17:15PM -0600, Rob Herring wrote:
> On Tue, Dec 4, 2018 at 7:22 PM Andreas Färber <afaerber@suse.de> wrote:
> >
> > Rob,
> >
> > Am 04.12.18 um 19:36 schrieb Rob Herring:
> > > I've put together a script to move the dts files and update the
> > > makefiles. It doesn't handle files not following a common prefix which
> > > isn't many and some includes within the dts files will need some fixups
> > > by hand.
> > >
> > > MAINTAINERS will also need updating.
> > >
> > > A few questions:
> > >
> > > Do we want to move absolutely everything to subdirs?
> >
> > This refactoring is a terrible idea!
> 
> How do you really feel?
> 
> > While it would've been nice to have more structure from the start,
> > bootloaders like U-Boot expect a flat structure for arm .dtb files now.
> > If you start installing them into subdirs instead, they won't find the
> > files anymore under the hardcoded name.
> >
> > Doing this only for new platforms would be much less invasive and allow
> > to prepare bootloaders accordingly.
> 
> That was my suggestion where this started for the new RDA platform.
> Olof preferred to move everything and that's my desire too.

I think we might really be stuck with "new stuff only in subdirs".
There's a whole huge world out there that depends on these layouts and
it's almost but not quite like the API vs ABI thing.  You can change the
kernel API at whim but this is something with a lot of external users,
and those folks aren't supposed to get broken.

> > Alternatively, white-list which ones
> > are safe to move around.
> 
> I'd prefer to know which ones the distros don't want moved. That
> should be easier to figure out. We also need that anyways in context
> of what platforms we care about compatibility.
> 
> Another option is dtbs_install target could flatten the installed
> dtbs. That is the only part the distros should depend on.

But it's not just "the distros" that'll get bit by this too.  Or rather,
it's the "big distros" and all the OpenEmbedded/buildroot/etc ones too
that follow off the built-in logic to find the DTB that'll get bit too
with a rename.

[snip]
> > DT overlays are another topic that is not making any progress upstream
> > according to the ELCE BoF, so beyond the Raspberry Pi the only known
> > working way to apply them is to write a U-Boot boot.scr script, which
> > can either reuse $fdtcontroladdr DT or use the filename $fdtfile or
> > hardcode one, the latter two of which would break with your renaming.
> 
> DT overlays also have nothing to do with this as there aren't any in
> the kernel. I'm not inclined to take any either with a flat tree.
> We're already at 1800+ files.

I'm going to do my best to not hijack the thread to be about overlays
but that's a whole chicken and egg type problem too.  But yes, it's not
exactly related to moving or not existing dts/dtb files but something
about where / how those are to be stored and maintained really does need
to be done.

-- 
Tom

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel