Re: [PATCH] ARM: /proc/atags: Export also for DT

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote:
> On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > > I'm fine with that, but we just need to have a standard kernel
> > > userspace interface in addition to something like
> > > /proc/device-tree/bootreason. Perhaps this can be the default
> > > implementation for the watchdog dev. Someday when we decide DT is crap
> > > and have a new boot interface, we'll have people relying on
> > > /proc/device-tree. I hope to be retired when that happens...
> > 
> > Anyone who thinks that DT can be replaced in the same way that we made
> > the mistake with ATAGs would really need their head examined.
> > 
> > As you point out, removing DT removes the /proc/device-tree/ sub-tree.
> > Whether we like it or not, that is a userspace API, one which we have
> > users of already.  That pretty much means that we can't remove DT for
> > existing platforms or any platform we have now converted to DT.
> 
> <ok, I'll go there!>
> 
> ... and for platforms that can also be booted via ACPI? If we have to
> convert the ACPI tables into a device-tree purely for /proc/device-tree,
> then we may as well boot with the thing too :)
> 
> Seriously though, I don't see how we can maintain this directory for
> ACPI, regardless of whether or not it's ABI.

And if it needs stating more clearly, you have just shown why adding
a boot reason to devicetree is the wrong thing to do.

Let's say that we do decide to convert the boot reason atag to a device
tree property.  As soon as we do that, it appears in the /proc/device-tree
sub-tree, whether we like it or not, because that sub-tree exports
*everything* mentioned in the DT blob.

So, as soon as we put anything into the DT blob, it immediately becomes
part of the kernel's userspace API, whether we like it or not.  That
means it becomes available for userspace to start (ab)using - again,
whether or not we provide a saner firmware independent interface.

The more we mess around converting crap from one firmware interface to
another, the more problems we're creating for ourselves.  We really
need to re-think our approach to this, and stop this religous "DT is
everything, we must convert everything to DT."

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.