| 1 |
On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote |
| 2 |
> On Tue, May 15, 2012 at 01:55:23AM -0400, Walter Dnes wrote: |
| 3 |
> > |
| 4 |
> > After some more Google-searching. it looks like the "official |
| 5 |
> > channels" way is via /etc/mdev.conf. Note that this is on a system with |
| 6 |
> > busybox[mdev] and no udev. /etc/mdev.conf has a rudimentary set of |
| 7 |
> > "mdev rules" abilities, and most importantly, it can also call external |
| 8 |
> > executables (scripts/programs/whatever). On my mdev based machines... |
| 9 |
> > |
| 10 |
> > $ cat /proc/sys/kernel/hotplug |
| 11 |
> > /sbin/mdev |
| 12 |
> |
| 13 |
> Oh my, don't do that. Please. It will slow your machine down, and on |
| 14 |
> some systems, and devices, cause fork-bombs causing your box to come to |
| 15 |
> a crawl and potentially die. There's also ordering issues that the |
| 16 |
> called program needs to resolve to get things right that add lots of |
| 17 |
> logic and slowdowns at times. I really want to get rid of that entry |
| 18 |
> and option from the kernel entirely, but need to keep it due to legacy |
| 19 |
> systems and API issues. |
| 20 |
> |
| 21 |
> But really, don't do that, it's not a good idea at all. |
| 22 |
|
| 23 |
During bootup, mdev is invoked as "mdev -s", and in hotplug mode it's |
| 24 |
simply "mdev". In hotplug mode, mdev returns some environmental |
| 25 |
variables, specifically "ACTION", which are not returned by "mdev -s". |
| 26 |
Any scripts launched by mdev can easily figure out whether they've been |
| 27 |
called at bootup or in response to a hotplug event, and act accordingly. |
| 28 |
A Google search turns up many hits about instructions for automounting |
| 29 |
under mdev, and it appears relatively easy. |
| 30 |
|
| 31 |
> What specifically is your objection to udev today? Is it doing things |
| 32 |
> you don't like? Too big? Something else? |
| 33 |
|
| 34 |
Today, it requires an initramfs if /usr is not physically on /. That |
| 35 |
is due in large part to the fact that it has been rolled into the |
| 36 |
systemd tarball, and inherited some of systemd's code and limitations, |
| 37 |
despite the fact that udev is still a separate binary. |
| 38 |
|
| 39 |
That's today. How long before it becomes part of the systemd binary? |
| 40 |
|
| 41 |
-- |
| 42 |
Walter Dnes <waltdnes@××××××××.org> |
Archives