1 |
On Tue, May 15, 2012 at 04:56:15AM +0300, Maxim Kammerer wrote: |
2 |
> On Tue, May 15, 2012 at 4:23 AM, Greg KH <gregkh@g.o> wrote: |
3 |
> > We learned that this is not a good idea at all, and should be left to userspace helper applications |
4 |
> > that listen for dbus messages. |
5 |
> |
6 |
> Could you perhaps expand a bit on those reasons? E.g., I had good |
7 |
> experience with the following short script for coupling udev events |
8 |
> with autofs: https://github.com/mkdesu/liberte/blob/master/src/usr/local/sbin/ps-mount. |
9 |
> Gentoo wiki has a similar tutorial as well. Granted, it is a |
10 |
> single-user setup, but I can imagine it being extended to work with |
11 |
> ConsoleKit. One obvious problem is mounting encrypted volumes. I |
12 |
> thought about moving to e.g., udisks-glue (as a more standard |
13 |
> solution), but from what I hear there are too many bugs with udisks at |
14 |
> the moment. |
15 |
|
16 |
I know of no such problem with udisks, have you reported them to the |
17 |
upstream developers? |
18 |
|
19 |
Yes, encrypted disks are one such problem, other bad things happen when |
20 |
you hit a disk with bad sectors, and other "fun" things. You can stall |
21 |
the whole hotplug path, causing issues and overruns. |
22 |
|
23 |
For more details as to why this is a bad idea, see the linux-hotplug |
24 |
mailing list archives, it was covered in detail there a few years ago. |
25 |
|
26 |
> > Actually with all the hype about mdev these days, why not just use a 3 |
27 |
> > year old version of udev (or maybe 4), that is probably what mdev is at |
28 |
> > as far as functionality goes. |
29 |
> |
30 |
> I don't know at what state udev was 3 or 4 years ago, but mdev can: |
31 |
> |
32 |
> 1. Populate /dev (now unnecessary due to devtmpfs). |
33 |
|
34 |
udev can't even do that these days (see, udev got smaller), as devtmpfs |
35 |
is what needs to do this. |
36 |
|
37 |
Right there, if that's all you need, and it's what most embedded systems |
38 |
need, udev isn't even needed, just use devtmpfs and all is fine. |
39 |
|
40 |
> 2. Handle ownership, permissions and symlinks to /dev nodes once they |
41 |
> appear, according to simple rules (can be probably done with inotify). |
42 |
|
43 |
Careful about user ownerships of multi-user machines, that gets tricky. |
44 |
|
45 |
> 3. Act as /sbin/hotplug, typically doing something equivalent to this one-liner: |
46 |
> [ "${ACTION}" = add -a -n "${MODALIAS}" ] && modprobe -qb "${MODALIAS}" |
47 |
|
48 |
Oh wow. Your /proc/sys/kernel/hotplug file should be set to "" if you |
49 |
want any chance to have a fast boot process. |
50 |
|
51 |
So, using mdev you slow your boot down, and slow down the response time |
52 |
from uevents. I don't think that's what you really want for a |
53 |
"lightweight" system :) |
54 |
|
55 |
> I don't think mdev can do anything else. Building any serious |
56 |
> framework on top of mdev seems pointless to me, since it will probably |
57 |
> end up as a small subset of udev core reimplemented with scripts. |
58 |
|
59 |
Again, what's wrong with just using udev for this as-is? What benifit |
60 |
can mdev provide you over udev? Is it somehow smaller? How small? |
61 |
It's obviously not faster due to the forking required from |
62 |
/sbin/hotplug, so that can't be a good reason to prefer it. |
63 |
|
64 |
thanks, |
65 |
|
66 |
greg k-h |