What was bug 1604?

[Denys Vlasenko]

On Tuesday 02 November 2010 20:49, Rob Landley wrote:
> > > Busybox umount was damaged by commit b2e578a1f2c3cf317 which made umount
> > > leak /dev/loopX entries by default, but didn't stop umount from
> > > auto-allocating the suckers.  So busybox mount/umount are now incoherent.
> > >  Wheee...
> >
> > Yes.
> >
> > > I have no idea what the rationale for this change was.
> >
> > Users got bitten by the unnecessary discrepancy between bbox umount
> > and util-linux one.
> 
> A) I believe util-linux added its -d option _after_ I rewrote the busybox 
> mount and umount commands.  They weren't there when I was looking at it to 
> figure out what to implement.
> 
> B) There is no mount/umount standard, so I don't see how this could be called 
> "standards compliance".
> 
> C) I made mount auto-allocate loop devices as appropriate without being told, 
> and similarly clean up after itself by default.  The existence of loop devices 
> is really a leaked implementation detail, something that should be internal to 
> the mount command anyway.  I made it fully automated so you didn't have to 
> care, and was working on a way to specify offsets and encryption keys (don't 
> remember if I actually implemented that) to eliminate the cases where losetup 
> needed to be called directly.
> 
> I.E. It was a design decision.
> 
> > They would rather prefer that both utilities, where
> > possible, have the same options to specify the same thing.
> 
> They being more than one person?

I don't know. When I put myself in the their shoes, I agree with them:
migrating from $BIG_DISTRO to busybox and finding that "umount -d" suddently
starts complaining about unknown option is wrong.


> > In this case,
> > util-linux umount has -d meaning "free loop device if there is one"
> > and we had -D "do not free loop device even if there is one".
> 
> Except that umount -a, or something like my zapchroot script, has no way of 
> knowing which entries are loop devices and which aren't, so you pretty much 
> always have to specify -d, which is harmless when it's _not_ a loop device.

Yes. However, is there a way to still free loop device, but not
bomb out on -d?

Yes. It's to accept but ignore -d. You are happy (you are not using -d anyway).
Former users of $BIG_DISTRO are mostly happy: "umount -d" doesn't bomb out.
(They are a bit unhappy about "umount" without -d not doing what it is
supposed to do, but are there many users who need that?)

This idea didn't occur to me at the time because I did not know that
keeping "always free loop device" behavior is important
for other group of people (namely, you).

We can also return -D option.


> > Bash isn't standard either, yet you do see why other Linux shells
> > should emulate bash, instead of only implementing POSIX shell.
> 
> Bash has a lot of useful extensions which would be fairly easy to implement, 
> so I was proposing that busybox grow a config option to support bash 
> extensions.  I was never proposing that we slavishly implement 100% of bash's 
> insane bloated behavior.  Remember, I was arguing _against_ the need to be 
> completely compatible with the strange {} expansion corner cases where the 
> behavior varied in non obvious ways that weren't even constant between bash 
> versions.
> 
> Adding a config option shouldn't break existing behavior.  You didn't add a 
> config option to umount, you broke compatability with what it was already doing 
> with no way to recover the old behavior.

See above. There is a way to do it. Do you see any holes in my proposal?

-- 
vda