What was bug 1604?
Rob Landley
rob at landley.net
Tue Nov 2 19:49:23 UTC 2010
On Sunday 31 October 2010 19:17:04 Denys Vlasenko wrote:
> On Sunday 31 October 2010 07:12, Rob Landley wrote:
> > The current bugzilla database hasn't got a 1604, and I dunno where mantis
> > is archived.
>
> I also don't have old mantis data.
> However, I did find a mantis-generated email about it:
>
> To: busybox-cvs at busybox.net
> Subject: [BusyBox 0001604]: umount -D
> Date: Fri, 23 Nov 2007 07:19:06 -0800
> From: bugs at busybox.net
> Message-ID: <64ddfd1c64a51be79d7292e780301214 at bugs.busybox.net>
>
>
> The following issue has been SUBMITTED.
>
======================================================================
> http://busybox.net/bugs/view.php?id=1604
>
======================================================================
> Reported By: alonbl
> Assigned To: BusyBox
>
======================================================================
> Project: BusyBox
> Issue ID: 1604
> Category: Standards Compliance
> Reproducibility: always
> Severity: minor
> Priority: normal
> Status: assigned
>
======================================================================
> Date Submitted: 11-23-2007 07:19 PST
> Last Modified: 11-23-2007 07:19 PST
>
======================================================================
> Summary: umount -D
> Description:
> Hello,
> I am not sure how to classify this...
> But util-linux does not have -D argument...
> The default behavior is not to free loop device allocation, unless -d is
> used.
> Any reason why busybox behaves differently?
> Thanks!
>
======================================================================
>
> Issue History
> Date Modified Username Field Change
>
======================================================================
> 11-23-07 07:19 alonbl New Issue
> 11-23-07 07:19 alonbl Status new => assigned
> 11-23-07 07:19 alonbl Assigned To => BusyBox
>
======================================================================
>
> > 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?
> 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.
> > By the way, any time you say "non-standard", reference which standard.
> > The mount and umount commands aren't in SUSv4. BSD used vnconfig,
> > slowaris used lofi, macosx does something vaguely like FUSE...
>
> Sure, there is no official, "paper" standard for mount utility.
No two unixes do this stuff the same way, and things like -d show up over time
so that if we follow them we have to break compatability with old versions of
our own implementation.
> 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.
My _rant_ about bash is due to Ubuntu being stupid. In the specific case of
Linux, bash was the first program Linux ever ran, before 0.0.1 shipped. Linus
extended his term program to implement the system calls bash needed which is
how it turned into a unix kernel in the first place. In that context, Ubuntu's
decision "oh, our init scripts run too slow, and changing them all to say
#!/bin/othershell at the top is too much work for us to maintain, let's
replace the shell #!/bin/sh points to after 15 years off that being a constant,
with the result that the linux kernel itself won't build under the resulting
system without patches" was an INSANE TECHNICAL DECISION.
So I hold a grudge against ubuntu for having removed it in 2006, especially
since the distro USED to have #!/bin/sh point to bash. They broke backwards
compatability with themselves.
Busybox has limped along for 10 years with deeply un-bash-like shells, and
that didn't stop people from using it. The situation could be _improved_, but
"not bash" wasn't fatal either. (Ok, trying to run the perl ./configure with
ash was a hilarious cascade of failure and segfaults, but defconfig defaults to
"ash" instead of "hush" so who tests the shell with an actual future?)
> You yourself told me this many times, and I agree with you.
>
> The situation with umount is analogous:
"Breaking existing behavior was bad, the regression should have been
reverted?"
Busybox umount never supported -d before this came up, it wasn't a regression
for us.
> There indeed *is* a version of umount utility used by the majority
> of Linux distros and "from scratch" installations: it's one from
> util-linux. For practical purposes, it is "standard Linux umount".
So remove the one from busybox if it's that important to use the One True
Version.
> If you don't like standard umount's options or behavior, there are ways
> to fix it:
>
> (a) join util-linux development team, and change it
> or
> (b) develop an alternative which will eclipse util-linux in popularity.
> But in order to eclipse it, you need to attract user base.
> And you won't be very successful in it if you break command line
> compatibility without good reasons.
Except now the behavior of busybox itself is inconsistent between versions.
You seem to consider "breaking existing busybox users" to be a rounding error
compared to following The One True Version's taillights.
I disagree. I don't see how treating busybox as a second tier project with no
independent existence, defined entirely in terms of being an "alternative" to
something else, could ever let it grow into anything more. So what's the
POINT?
You're the maintainer, my opinion on these issues doesn't really _matter_
anymore, so there's not much point in me continuing to argue about it. I
disagree, but life goes on.
Rob
--
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem
Forever, and as welcome as New Coke.
More information about the busybox
mailing list