[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Thu, Nov 14, 2013 at 11:28:59AM -0500, Jason Cooper wrote:
> This is the difference between a commercial effort and a hobbyist
> effort.  I think I have a plan for how we can both get what we want.  I
> could change the argument to 'dtc ... -L arch/arm/boot ...'.  Thus:
> 
> $ cd arch/arm/boot
> $ ls -l *.dtb        # minus a few columns
> ...
> globalscale,mirabox.dtb -> dts/armada-370-mirabox.dtb
> ...
> 
> 
> This way, aftermarket users (debian installers, etc) could go to the
> same place they go for zImages, and find a standard named dtb.  They
> wouldn't need to parse the dtbs, just look at the current compatible
> string for the board they are installing on and find the matching file.

There's little point saying that they should be in arch/arm/boot.
Unless the distro is installing from a kernel source tree on every
platform, the location of the dtbs really doesn't matter.

Let's look at the typical distro build process:

- take the source
- patch it
- build it
- install it, relatively placing files according to their ultimate
  destination
- packaging the result up, adding metadata and scripts to aid installation

So, how does affecting where things are in the build tree help after all
that process?  What matters for DT files are:

(a) their names
(b) their location after installation

Where it appears in the build tree is neither here nor there, and IMHO
should not be of concern to any distro - just the same as picking the
zImage/uImage/whatever out of arch/arm/boot is none of their business.

We have ways and means to deal with the installation of kernel images
and modules.  There's well defined makefile targets for this, and
make variables which control where and how these get put.  For the
kernel image, you can specify the script to be run (which is called
with the location of the *Image file) for copying.  Pulling it manually
out of arch/arm/boot is really a failure of the distro packaging people
to get their process right.

The same goes for the DT files: if we don't provide a method for the
kernel build system to install these in a sane way, then that's our
failing.  However, distros should be asking for this, and not picking
the files out of arch/arm/boot/dts.

As for the commercial vs hobbist, there's very little difference here.
If you're a hobbist, building natively, that's where having the right
/sbin/installkernel present is a godsend, especially if you're running
some distro.  If you don't, most likely you understand what's required
to install a kernel.

Last point - on the Carrier-1, I have a fully automated setup which I
can fire off a build, walk away, and it will build a kernel including
modules, install it locally on my x86 PC in ~/systems/imx6 - including
appending the DT file, tar up the appropriate files, automatically copy
the tar file over, unpack it, update the initramfs for ubuntu 12.04,
update the vfat /boot filesystem appropriately, and reboot the platform.

Yes, I know the target system with that.  That's not my point.  The point
I'm making is that that level of automation is possible without excessive
amounts of messing about with kernel build internals - that all runs with
standard unmodified kbuild.

So, maintain a sense of perspective and separation of stages please.