On 08/12/2016 18:28, Felix Fietkau wrote:
> On 2016-12-08 18:17, John Crispin wrote:
>>
>>
>> On 08/12/2016 18:10, Felix Fietkau wrote:
>>> On 2016-12-08 18:08, John Crispin wrote:
>>>>
>>>>
>>>> On 08/12/2016 18:06, Felix Fietkau wrote:
>>>>> On 2016-12-08 17:31, John Crispin wrote:
>>>>>> Hi,
>>>>>>
>>>>>> i was planning to start working on this in early 2017. i was hoping that
>>>>>> rather than converting ar71xx to DT we simply create a new target called
>>>>>> ath79 and start moving board support over from the legacy to the new
>>>>>> target. this would allow us to make the ath79 target much cleaner than
>>>>>> having to worry about legacy cruft.
>>>>>>
>>>>>> converting all the mach files to dts files is also a bit tricky. back in
>>>>>> the day when i converted ramips, i simply create a host lib that
>>>>>> provided all the platform_*() callbacks used by the mach files. however
>>>>>> rather than register anything the code simply generated the matching dts
>>>>>> files. this was really ugly, run once and throw away code.
>>>>>>
>>>>>> can you share the patches you have already created ? i think we could
>>>>>> start working on this now and once the new ath79 target starts to be
>>>>>> usable we simply refuse to merge patches to ar71xx and only accept ones
>>>>>> for ath79
>>>>> I think making this a separate target will make the transition period a
>>>>> lot more confusing for users. I think it should not be too hard to
>>>>> support both DT and non-DT devices with the same kernel.
>>>>>
>>>>> I fully agree with refusing to accept non-DT device support once a few
>>>>> devices work with DT.
>>>>>
>>>>> - Felix
>>>>>
>>>>
>>>> how would that be confusing ? i would argue the exact opposite
>>> Because suddenly there are two targets and you have to look up which
>>> device is supported by which target.
>>>
>>> - Felix
>>>
>>
>> its a tradeoff we need to consider
>>
>> 1) chance to start a new clean target without legacy cruft
>> 2) making it easy to find the snapshot
>>
>> i would value 1) higher than 2)
> I would also like to avoid duplicating things like the ethernet driver,
> SPI drivers, the NAND drivers and the patches unrelated to DT and mach-*
> stuff.
>
> Also, it's not just about finding the snapshot images. This split is
> also quite annoying for people building from source. In some cases
> people maintaining their own builds for a group of devices might then
> need to start dealing with building multiple targets instead of one, and
> will have to re-check frequently if devices moved from one target to the
> other.
>
> Maybe a good first step would be to reorganize the patches and split
> them into parts ready for upstreaming and parts that contain legacy
> stuff that still needs to be cleaned up.
>
> I'm not going to veto any of the different approaches, the decision
> should be up to the people doing the actual work.
> However, I think this is an important factor to consider.
>
> - Felix
i did not think about mass building of images and fixing ethernet driver
bugs in 2 trees. i'll need to think about this a bit more.
John
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
