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