On Sun, Oct 10, 2010, Zenaan Harkness wrote: > On Sun, Oct 10, 2010 at 2:13 PM, Adrian Chadd <[email protected]> wrote: > > The horrible, O(n) way is to just to loop over 0 .. n, see if it doesn't > > exist, if it doesn't then create and use it. > > > > It's slow, it's racy (ie, don't run the script without locking :-) but > > it's a traditional UNIX way of doing things. > > Think I'll avoid that on principle. Providing a minor # at all seems > strange to me. Like Linux should do it. Why do I want or need to know > about these MINOR #s anyway?! All I want is an lo dev; far away from > this cold nightmare (with apologies to Frederick Loewe). > > At least losetup is an ELF exe, so if it does the anything similar it > should be a little quicker, non-racy, and debugged than my own shell > script, notwithstanding statically pre-allocated dev nodes. One can > hope :)
Well, the binary/kernel may: * loop over /dev/loopX, hoping you've got them there; * do some ioctl on a device (eg /dev/loop), be told a device that's been created for it, and open that * clone the device - eg you open /dev/loop, it creates /dev/loopX and makes your FD map to that I know the latter is what FreeBSD's cloning devices do. That way it's not prone to race conditions. Don't assume that binaries are debugged and work properly. You may find it's only assumed to work in certain, low-frequency-of-use situations. :-) I suggest reading what losetup does to obtain a binary. Pay special attention to ensure if it is looping over /dev/loopX, it actually -is- doing some form of locking. :) 2c, Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
