[Toybox] losetup checked in.

[Rob Landley]

I finished losetup (more or less a prerequisite to mount/umount, which  
are up nextish). It turned out to be a lot fiddlier than I remembered  
because it's developed a bunch more options, such as -f which uses  
/dev/loop-control now to create and delete loop devices.

Basically /dev/loop-control works like /dev/pts does with ptys, and  
/dev/loop[0-9]* work like the old static /dev pty entries. In theory  
we're migrating over to the dynamic ones completely at some point.

I left a pending issue I don't know how to deal with: that there are a  
certain number of pregenerated /dev/loop devices and I don't know how  
to tell how many. (There's a kernel compile time option that sets a  
default, and it can be overridden on the command line.) I can see how  
many there are _now_, but not how many the system wants to keep around  
even if they're idle.

The -f option iterates through the existing ones to find unused  
entries, and if it doesn't find any it can also create new ones with  
/dev/loop-control (which are created immediately on devtmpfs, or show  
up after a few miliseconds delay for an asynchronus callback with  
udev/mdev: I just assumed you're using devtmpfs because that's the sane  
option and udev/mdev can run on top of devtmpfs anyway).

In _theory_ the -d option can undo -f and delete loop devices, but the  
pending issue is I dunno _when_ to do this. I can tell how many loop  
devices there are now, but not how many the system started with and  
wants to ekep around even if they're idle.

So right now -f can add /dev/loop[0-9]* nodes when it runs out, and  
then they persist until the next reboot. I.E. the number that hang  
around as empty waiting to be reused goes up, but never goes down.

(I didn't implement any of the cryptoloop stuff because encryption  
belogs at the device mapper level. I can go back and stick it in if  
anybody really misses it...)

Rob
 1357782108.0