On Mon, May 14, 2012 at 03:53:53AM -0400, Walter Dnes wrote: > After some Google-searching, I think I've figured out how to implement > automounting under mdev. I'd like to put in as much sanity-checking > into the script as possible. Right now I have 1 USB stick plugged in as > /dev/sdb. Th hard drive is /dev/sda. The "removable" data is readable > like so... > > cat /sys/block/sda/removable > 0 > > cat /sys/block/sdb/removable > 1 > > My question... is this API stable or deprecated? I.e. can I count on > it being around for a while? I figure this question is a developer type > question rather than ordinary user type.
You might want to look at Documentation/ABI/ in the kernel source tree if you are curious about sysfs files like this. As you have figured out, this really doesn't mean what you think it does. In fact, there's no way to determine what I think you are asking for, which is "can this disk go away", as really, any disk can go away at any point in time, just like any disk can show up at any point in time as well. Think PCI hotplug systems, thunderbolt, pcmcia, ExpressCard, Firewire, USB, SCSI, etc. So you need to implement stuff such that you are not dependant on the bus type. If you see a new disk, act on it, it's that simple. But note, please do not be automounting disks from uevents directly. As someone else said on this thread, "those that have not learned from the lessons of udev, will implement it poorly". We learned that this is not a good idea at all, and should be left to userspace helper applications that listen for dbus messages. Both GNOME and KDE work this way quite well, so I would be very wary of reimplementing the wheel. Actually with all the hype about mdev these days, why not just use a 3 year old version of udev (or maybe 4), that is probably what mdev is at as far as functionality goes. Why not just fork udev from then and go forward from that? What exactly are you not liking in udev that makes you want to get rid of it so badly? What is it doing that bothers people so much? Good luck, greg k-h
