On Sat, Feb 19, 2022 at 11:05:23AM -0800, Luis Chamberlain wrote: > Indeed. The issue is that dropping that also does not allow the > association of extra custom higher number loop block nodes created manually > even if you *do* load a respective module before use. That is by design > by the commit, since we're stuffing the nasty old probe logic now under the new > CONFIG_BLOCK_LEGACY_AUTOLOAD. Subtle difference, but same deprecation > effect. > > I agree with the approach to stuff all this nasty cruft under > BLOCK_LEGACY_AUTOLOAD however I suspect v5.19 might be too soon to tell if we > can nuke it safely by then though. Yeah. 5.19 was planned when I submitted this for 5.17, but with it appearing in 5.18 it is far too early anyway. > I'd go so far as to say that we should sadly make > BLOCK_LEGACY_AUTOLOAD=y for a while before going with an axe to kill it. > I think we have a few hidden gems we'll soon discover might need a bit > more time to adjust. Probably. > > FWIW below is a simple test, which now fails to explain what I mean with > the above. > > root@kdevops ~ # cat loop-high-devs.sh The interesting part is that the script works if I remove this mknod: > if [[ ! -e $LOOPDEV ]]; then > mknod $LOOPDEV b 7 $NUM > fi so it seems like losetup is trying to be smart here and skip the manual creation if the device exists. I'll take a look at the code and wіll prepare a patch for that.
