Re: devicetree repository separation/migration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2/20/2014 12:14 AM, Grant Likely wrote:
> On Thu, Feb 20, 2014 at 4:58 AM, Frank Rowand <frowand.list@xxxxxxxxx> wrote:
>> On 2/19/2014 1:15 PM, Grant Likely wrote:
>>> On Wed, Feb 19, 2014 at 8:16 PM, Frank Rowand <frowand.list@xxxxxxxxx> 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.
>>>
>>> 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.
>>
>> We could provide an easy export (see below).  What do you think?
> 
> Ian Campbell is already maintaining an export tree as a staging area
> for an eventual split. He's had it up and running for almost a year
> now:
> 
> http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git
> 
> g.
> 

So there already is a "good way to share the database of hardware
descriptions" in addition to the one I provided.

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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux