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