What was bug 1604?
Denys Vlasenko
vda.linux at googlemail.com
Tue Nov 2 20:37:29 UTC 2010
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
More information about the busybox
mailing list