Message-ID: <CAKON4Owg7guXo7TjtW3_C2Q07jNT8L6f6648AwXYBOxx2GA28w@mail.gmail.com>
Date:	Sat, 27 Jul 2013 15:22:52 -0400
From:	"jonsmirl@...il.com" <jonsmirl@...il.com>
To:	Tomasz Figa <tomasz.figa@...il.com>
Cc:	Richard Cochran <richardcochran@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"ksummit-2013-discuss@...ts.linuxfoundation.org" 
	<ksummit-2013-discuss@...ts.linuxfoundation.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Ian Campbell <ian.campbell@...rix.com>,
	Pawel Moll <Pawel.Moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Domenico Andreoli <cavokz@...il.com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Olof Johansson <olof@...om.net>,
	Mark Brown <broonie@...nel.org>,
	Arend van Spriel <arend@...adcom.com>,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]

On Sat, Jul 27, 2013 at 2:51 PM, Tomasz Figa <tomasz.figa@...il.com> wrote:
> On Saturday 27 of July 2013 20:31:01 Richard Cochran wrote:
>> On Sat, Jul 27, 2013 at 12:24:24PM +0200, Arend van Spriel wrote:
>> > That is a nice summary of how we got from null to now and Richard
>> > seems to be simply saying: let's stop mucking about and make this a
>> > project with a well-defined process of dealing with staging and
>> > stable bindings and keep stable bindings stable.
>>
>> Yes, that is right.
>>
>> Frankly, I am really surprised and shocked at the cavalier attitude
>> expressed here WRT DT bindings in released kernels. Think about the
>> *users* of this code. Not everyone working with ARM Linux is a kernel
>> developer or a DT guru. There is really no indication at all that the
>> ARM Linux DT stuff released so far are not stable and trustworthy.
>>
>> It is not nice to provide such a mess, and the idea that we *must*
>> have a mess because the whole system in still in development is bogus,
>> IMHO. Just make sure that the mainline kernel is really working and
>> that the DT bindings *there* are for keeps.
>>
>> It is your job as kernel developers.
>
> Well, it depends on how we use the DT. There are (at least) two possible
> usage scenarios:
>
>  a) using DT as direct replacement for board files - this means that you
>     are free to say that DTSes are strictly coupled with kernel version
>     and you are free to modify the bindings - see the analogy to board
>     files, where you could modify the platform data structures and could
>     not directly copy board file from one kernel version to another,
>
>  b) using DT as an ABI - this is the original way, i.e. define stable
>     bindings and make sure that anu DTB built for older kernel will work,
>     with equal or greater set of functionality on newer kernels.

c) There was very good suggestion earlier about using quirks to fix up
legacy DTBs.  I really like that since the DTB can both be an ABI and
we can continue to evolve the kernel. The quirk code will have little
impact since it will be run at boot time and then discarded.

So there would be an evolving schema that represents the device tree
as understood by a particular kernel.  And then there would be a bunch
of quirks for converting the 'legacy' deployed DTBs into this
tree.These deployed DTBs are only the ones in boot loaders since they
are the only ones that can be seen by multiple kernels.

There are a lot of good places in this process to attach error
checking. For example the quirk code could complain about any DTBs it
is unable to fix up. And verifying things against the schema provides
a single point of contact for device tree design. The universal schema
will force discussion of how to create generic bindings for things
like DMA controllers.

Plus it is still possible to experiment in this model. Bind your DTB
to the kernel. Those DTBs won't be run through the quirk code. You'll
be able to have experimental elements that dtc will flag as not
matching the schema but they'll still be there.

Evolution also works very well. Each release of the kernel will
archive the schema and quirks at the point in time when it is
released.


>
> Now I believe in this thread the point whether we should use a) or b) or a
> combination of both has been raised.
>
> As for current situation, from users' perspective it's almost no
> difference. With a) they can use appended DTB feature (or hack, whatever
> you prefer). With b) they just upload new zImage/uImage/whatever, leaving
> old DTB as is, if they don't want any new functionality. If there is
> support added for new functionality, they must update their DTBs anyway,
> so there is no clear advantage of b) over a) in this matter.
>
> So, basically, this is not an obvious issue. Without analyzing (and
> discussing) possible use cases, issues, consequences and whatever, there
> is no obvious answer, such as "just stabilize whatever we have now!" or
> "go back to board files!".
>
> We have what we have, it is not perfect, some things have been screwed up,
> but we can't just leave that behind and say "now we'll be doing everything
> correctly", we must fix that up. People don't do everything correctly from
> the start, this is what the whole staging vs stable topic is about.
>
> Best regards,
> Tomasz
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Jon Smirl
jonsmirl@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists