On Mon, Jan 21, 2013 at 6:55 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
> On Mon, Jan 21, 2013 at 6:51 PM, Brendan Conoboy <blc(a)redhat.com> wrote:
>> On 01/21/2013 03:38 PM, Peter Robinson wrote:
>>>
>>> On Sun, Jan 20, 2013 at 8:09 PM, Brendan Conoboy <blc(a)redhat.com> wrote:
>>>>
>>>> Slight correction: plan is to add a kernel sub package in 3.7 that
>>>> includes dtbs. This won't go in the rc since the rc will be 3.6 based.
>>>
>>>
>>> Why a kernel sub package? Why don't we add the dtb files for the
>>> platforms that will work to the kernels that support it. We will
>>> support half a dozen omap devices (and maybe include a few others that
>>> might work) but there's no point shipping 100s of dtb files for
>>> devices that we don't even enable the SoC for.
>>
>>
>> I don't have a firm opinion on this except that we should make a sustainable
>> decision. In my book all that really matters is that upgrading the kernel
>> from 3.6 to 3.7 allows the systems we support to continue booting (and 3.7
>> to 3.8, etc). In my book that means the kernel provides the dtb (or
>> requires a subpackage that contains the dtb). And the boot script knows to
>> load the dtb if it's available. Wwe might as well do it the way we mean to
>> keep on doing it, so picking good paths for these dtbs makes sense. There
>> will presumably be quite a few of these files with kernel unification.
>
> I think then it should be as part of the kernel. We can make a better
> decision and they are small so I don't see splitting it into another
> file makes sense. The directory should be default like the firmwares
> do but again we should be going with an upstream standard.
Not sure why the list got removed but re-adding.
Peter