Re: devicetree repository separation/migration

[Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 2/19/2014 1:15 PM, Grant Likely wrote:
> On Wed, Feb 19, 2014 at 8:16 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 2/19/2014 1:08 AM, Sascha Hauer wrote:
>>> On Tue, Feb 18, 2014 at 02:44:15PM -0800, Tim Bird wrote:
>>>> I'm not in favor of separating the device tree information from the kernel.
>>>>
>>>> If we switch, then whatever synchronization issues other projects
>>>> are having now with synching with the device tree info from the kernel will
>>>> just then become the problem of the kernel developers, who will then
>>>> have to sync with the device tree info from another repository.  If the
>>>> sync issues can't be solved now for them, why or how would it be solved
>>>> post-separation for us?  (It sounds like a zero-sum game of pain transfer
>>>> to me.)
>>>>
>>>> I'm relatively unfamiliar with the arguments.  Can someone provide
>>>> a brief list of reasons this is needed, and how the inconvenience to Linux
>>>> kernel developers will be minimized, should it proceed?
>>>
>>
>>
>>> One of the reasons for doing devicetrees is to separate the hardware
>>> description from the code so that:
>>> - Other OSes (and bootloaders) can use the same description to start on
>>>   a given hardware
>>> - A generic Kernel can be started on any hardware
>>> - A hardware describes itself, makes itself more introspecitve so we can
>>>   go away from very specialized kernels
>>
>> Tim knows this ^^^^.  He was asking for the arguments for moving dts files
>> out of the linux kernel source tree.
> 
> We've made the decision that devicetree bindings need to be treated as
> ABI, but as long as the .dts files live in the kernel there will
> always be the temptation to just tweak things in lock-step and nobody
> will notice. Splitting the files out gives that extra push to think
> about whether changes to a binding will backwards compatible with a
> tree that doesn't have those changes because the chances are a lot
> higher that someone will hit that combination.

We have other ABI in the kernel.  The maintainers have to develop a
spine if they are letting the supposed ABI changes occur they way
you suggest.

I thought that the actions flowing out of Edinburgh were supposed to
move us in the direction of developing the ABI mentality, and the
process to allow development and experimentation to occur (with a
clear label that they were not yet ABI) then a way to decide that
the development of a devicetree binding was complete enough to be
ABI.

> 
> The other argument is shared source between
> BSD/U-Boot/Barebox/Linux/etc. Until we have a separate .dts repo there
> is no good way to share the database of hardware descriptions.
> 
> g.
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html