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

[Simon Glass]

Hi Tom,

On Wed, 21 Nov 2018 at 08:10, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Nov 20, 2018 at 08:53:12AM -0500, 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.
> >
> > > >> 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).
>
> And, for the record, the USB side I had in mind here was converted, and
> I just forgot, my fault.  In fact, as I go through some hack-and-slash
> to see what needs a real conversion (either board updated, or drivers
> updated) at least some part of this is needing to adjust dependencies to
> force things on with BLK.  For example, if we have MMC we must have
> DM_MMC and BLK, and if we have USB we must have DM_USB and BLK.

Well, once we are through the migration we can remove BLK.

Yes all the block devices are related, and we should use DM for all of
them to make this work.

I am not sure if there is a better way to do this with Kconfig.

Thanks for helping with all of this. I have found it quite tricky to
plot a path forward which is why I am been putting it off for several
months.

Regards,
Simon