[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

On Mon, Nov 18, 2013 at 12:38:11PM -0700, Stephen Warren wrote:
> On 11/18/2013 12:28 PM, Jason Cooper wrote:
> > On Mon, Nov 18, 2013 at 12:23:48PM -0700, Stephen Warren wrote:
> >> On 11/18/2013 12:19 PM, Jason Cooper wrote:
> >>> On Mon, Nov 18, 2013 at 12:09:19PM -0700, Stephen Warren wrote:
> >>>> On 11/18/2013 11:38 AM, Jason Cooper wrote:
> >>>>> Unlike other build products in the Linux kernel, the devicetree blobs
> >>>>> are simply the name of their source file, s/dts/dtb/.  There is also no
> >>>>> 'make *install' mechanism to put them in a standard place with a
> >>>>> standard naming structure.
> >>>>>
> >>>>> Unfortunately, users have begun scripting pulling the needed dtbs from
> >>>>> within the kernel tree, thus hardcoding the dtbs names.  In turn, this
> >>>>> means any changes to the dts filenames breaks these scripts.
> >>>>>
> >>>>> This patch is an attempt to fix this problem.  Akin to 'make install',
> >>>>> this creates a new make target, dtbs_install.  The script that gets
> >>>>> called defers to a vendor or distribution supplied installdtbs binary,
> >>>>> if found in the system.  Otherwise, the default action is to install a
> >>>>> given dtb into
> >> ...
> >>>> This only appears to create ${compat}.dtb, and not ${dtb} too. 
> >>>
> >>> See my comment, above.
> >>>
> >>>> So, it doesn't seem to address part of the cover letter, "In addition,
> >>>> some vendors have done a diligent job naming their devicetree source
> >>>> files appropriately and we don't want to break their setups." Was that
> >>>> deliberate? If so, I guess I need to send some patches to U-Boot.
> >>>
> >>> I assume you are still pulling from arch/arm/boot/dts/*.dtb, right?
> >>> Those build products don't go away with this patch, so you should be
> >>> fine.  Unless I'm mis-understanding your workflow...
> >>
> >> Yes, but I thought the whole point of this was that everyone would/could
> >> switch to running "make dtbs_install", then pulling out the files from
> >> the install tree, instead of any use-case requiring obtaining files
> >> directly from the source/build tree?
> > 
> > Yes, in the script, it checks for the existence of /sbin/installdtbs.
> > If it's there, it will override the default behavior and execute that
> > script.
> 
> But that means everyone (a lot of people, and all distros) has to write,
> or at least download and install, such a script. 

They would already be modifying their build environment to make use of
'make dtbs_install', and few extra lines of shell script to integrate
with existing systems certainly isn't unreasonable?

> Equally, that script would incorrectly affect the naming of non-Tegra
> DTBs that follow the new convention. The naming of the Tegra DTBs is
> based more on the fact that they're the Tegra DTBs than the fact that
> I'm using them.

Umm, I wrote that script in 2 minutes.  I'm sure you could come up with
something Tegra-specific (perhaps using fdtget?) that places only the
Tegra dtbs in the location that works with Tegra's u-boot.

The point is, we're trying to set a reasonable default, _and_ respect
the pre-existing workflows.  I don't think 15 lines of script is too
much to ask.  Especially since it would be written to adopt a *new*
workflow, not fix a workflow broken by callous kernel maintainers. ;-)

thx,

Jason.