On Mon, Apr 16, 2012 at 6:02 AM, Rob Landley <[email protected]> wrote: > On 04/15/2012 08:19 PM, Denys Vlasenko wrote: >> I agree, and I will implement that if util-linux's umount does the same. >> Does it? > > Why on earth would that matter?
Script compatibility. > The position here seems to be "oh no, we can't be better than other > implementations". I do not understand this position. > > The busybox mount command I wrote 6 years ago autodetected the need for > --loop when you did "mount file dir". The util-linux one didn't, and > still doesn't. The busybox behavior was an improvement, especially since > the util-linux mount behavior was STUPID: > > $ sudo mount tccboot.iso reference > mount: /home/landley/qemu/images/tccboot.iso is not a block device > (maybe try `-o loop'?) > > I.E. it knows what you want to do, and _tells_ you it knows what you > want to do, but refuses to do it unless you say please. I wrote my > implementation to just _do_ it. > > Similarly, the busybox umount command also autodetected the need to > deallocate an unmounted loop device. At the time, this was also an > improvement. Since then, util-linux grew yet more complicated behavior, > from the man page: > >> the Loop Device >> The umount command will free the loop device (if any) associated with >> the mount, in case it finds the option 'loop=...' in /etc/mtab, or >> when the -d option was given. Any pending loop devices can be freed >> using 'losetup -d', see losetup(8). > > I.E. it looks for loop= in mtab, which you won't get if /etc/mtab is a > symlink to /proc/mounts. It's a complicated, roundabout bit of > unnecessary code, which breaks. > > The ioctl you call on loop devices to deallocate them is harmless: if > the device is in use it won't break other uses of it, and it isn't used > by anyone else. And yes, I looked this up at the time: according to > linux/documentation/ioctl/ioctl-decoding.txt bits 15-8 of the ioctl > number are intended to be unique to each driver. In practice loop.c, > the scsi driver, and the encrypted disk driver have range overlap, but > according to ioctl-number.txt entries 0x00 through 0x0F are only used by > the loop driver, and the ioctl to disassociate a loop device (0x4c01) is > unique to the loopback driver, thus calling it on the block device we're > unmounting will be ignored (return an error) on any other type of block > device. If the block device is in use elsewhere this will also return > an error and refuse to deallocate the loop device (I tested it). Thus > it's safe to call unconditionally from umount, which is the simple > behavior I implemented in 2006. > > That's why I put this comment, which was still there in the commit that > removed -D: > > + // De-allocate the loop device. This ioctl should be ignored on > + // any non-loop block devices. > > I really don't understand this deference to the limitations of > util-linux. I want to avoid people writing scripts which work with busybox applets but "mysteriously break" on big distros. Your arguments about umount behavior make a lot of sense. Does anyone volunteer to talk to util-linux people to make them adopt some or all of these proposals? -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
