[U-Boot] [PATCH 00/93] dm: Move towards completing CONFIG_BLK migration

Marek Vasut marek.vasut at gmail.com
Tue Nov 20 13:55:02 UTC 2018


On 11/20/2018 02:53 PM, Tom Rini wrote:
> On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote:
>> On 11/20/2018 02:42 PM, Tom Rini wrote:
>>> On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote:
>>>> On 11/20/2018 02:37 PM, Tom Rini wrote:
>>>>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote:
>>>>>>
>>>>>>
>>>>>> On 19.11.18 16:52, Simon Glass wrote:
>>>>>>> All boards should now be migrated to use CONFIG_BLK. This series removes
>>>>>>> those with build problems using this option.
>>>>>>>
>>>>>>> If maintainers want to keep these boards in they should send a patch in
>>>>>>> the next week or two. Otherwise the board will be removed in the next
>>>>>>> release, and will need to be added and re-reviewed later.
>>>>>> Fabio, Stefano,
>>>>>>
>>>>>> it seems (almost?) all i.mx6 boards should be removed within two weeks.
>>>>>> But would it not make more sense to convert the reference boards first
>>>>>> (mx6sabresd
>>>>>> in my case for tbs2910), and let hobbyist maintainers like me take this
>>>>>> as example for
>>>>>> their own modifications?
>>>>>
>>>>> So, I replied to the main thread earlier but no, we're not going to drop
>>>>> everything in 2 weeks, especially since there's a lot of false positives
>>>>> in this series.
>>>>>
>>>>>> Simon, Tom,
>>>>>>
>>>>>> is this really the usual u-boot working style to remove about hundred
>>>>>> boards within
>>>>>> two weeks without prior warning? As hobbyist board maintainer I try to
>>>>>> follow
>>>>>> new developments, and more than once I fixed up regressions introduced
>>>>>> by others
>>>>>> in general code.
>>>>>> But I cannot follow all development details without any heads-up. And
>>>>>> even the
>>>>>> NXP folks seem to be surprised about this.
>>>>>>
>>>>>> All problems with this transition seem to be located around usbstorage
>>>>>> and sata.
>>>>>> This is for sure not really very board specific. Is there any migration
>>>>>> guide, or
>>>>>> examples how other SoC architectures did this conversion?
>>>>>
>>>>> I'll admit this hasn't been our best notification.  But, the deadline
>>>>> was discussed about a year ago (and then no, I didn't get a build-time
>>>>> warning in).  Then around v2018.05 I said it wasn't going to be a
>>>>> removal type problem yet as we had a lot of boards to fixup still, and
>>>>> repeated that at v2018.07.  That did lead to a lot of things getting
>>>>> addressed.  But yes, we still have some large areas that after a few
>>>>> years still have not been converted, and that puts me in a hard spot
>>>>> too.
>>>>
>>>> Build time warning for a year would be good ?
>>>
>>> A year for this?  No.  New deadlines?  That's not too far off from what
>>> we've done historically, so yes.
>>
>> Give people some sort of breathing space to get the conversion done.
>> Stressing people out by arbitrary deadlines will lead nowhere.
> 
> Sure, agreed.  I didn't say we're going to drop all these boards, nor
> are we going to drop SATA and USB Storage (if those are still all that's
> left to convert) for this release.  But given that we proposed a
> deadline in August 2017, made email-but-not-build noise about it between
> May and July/August of this year, no, I also don't think setting a new
> deadline of November 2019 is the right call either.
> 
> So, really, lets see what the fails to build boards are with BLK being
> on when we have block devices.  Then assess what a good deadline is.

Sounds good.

>>>> Maybe we need some generic Makefile macro to set those up.
>>>
>>> It would be nice, yes.  I think the problem here is (or, was) the
>>> complex set of options that didn't work.
>>
>> The problem was many people didn't know about the conversion deadline or
>> simply forgot. And reminding them with a 100-patch series removing half
>> of the boards is like splashing icy water bucket in their sleeping faces.
> 
> Alright.  But we've already tried less shocking approaches to
> conversion, but in public (over the summer when Simon listed most of
> these boards in a series but I _think_ his script failed to CC the
> universe and didn't follow up with a repost that did email everyone) and
> perhaps private too (I honestly don't recall if I did, or just intended
> to, ask you about the USB side of this on IRC).

I think the Makefile noise would be good. It'd be annoying enough and
persistently remind people to fix their stuff.

-- 
Best regards,
Marek Vasut


More information about the U-Boot mailing list