1 |
On Tue, May 15, 2012 at 01:55:23AM -0400, Walter Dnes wrote: |
2 |
> On Mon, May 14, 2012 at 06:23:36PM -0700, Greg KH wrote |
3 |
> |
4 |
> > So you need to implement stuff such that you are not dependant on the |
5 |
> > bus type. If you see a new disk, act on it, it's that simple. |
6 |
> > |
7 |
> > But note, please do not be automounting disks from uevents directly. |
8 |
> |
9 |
> After some more Google-searching. it looks like the "official |
10 |
> channels" way is via /etc/mdev.conf. Note that this is on a system with |
11 |
> busybox[mdev] and no udev. /etc/mdev.conf has a rudimentary set of |
12 |
> "mdev rules" abilities, and most importantly, it can also call external |
13 |
> executables (scripts/programs/whatever). On my mdev based machines... |
14 |
> |
15 |
> $ cat /proc/sys/kernel/hotplug |
16 |
> /sbin/mdev |
17 |
|
18 |
Oh my, don't do that. Please. It will slow your machine down, and on |
19 |
some systems, and devices, cause fork-bombs causing your box to come to |
20 |
a crawl and potentially die. There's also ordering issues that the |
21 |
called program needs to resolve to get things right that add lots of |
22 |
logic and slowdowns at times. I really want to get rid of that entry |
23 |
and option from the kernel entirely, but need to keep it due to legacy |
24 |
systems and API issues. |
25 |
|
26 |
But really, don't do that, it's not a good idea at all. |
27 |
|
28 |
> > Actually with all the hype about mdev these days, why not just use a 3 |
29 |
> > year old version of udev (or maybe 4), that is probably what mdev is at |
30 |
> > as far as functionality goes. Why not just fork udev from then and go |
31 |
> > forward from that? What exactly are you not liking in udev that makes |
32 |
> > you want to get rid of it so badly? What is it doing that bothers |
33 |
> > people so much? |
34 |
> |
35 |
> Unfortunately, I am not a C programmer, so forking udev is only a |
36 |
> dream. As Maxim has pointed out, mdev does what most people need. |
37 |
|
38 |
As does udev. And udev is faster, and I'd bet, the same size. |
39 |
|
40 |
> The busybox people do the maintenance. Given their target audience |
41 |
> (embedded and lightweight systems), we can be certain that mdev won't |
42 |
> grow into a monstrosity. Even if I could do it, why reinvent the |
43 |
> wheel? We have a perfectly usable alternative right now in mdev. |
44 |
|
45 |
mdev is the reinvention, but hey, if you want it, that's fine. Embedded |
46 |
and "lightweight" systems don't even need mdev or udev, they just use |
47 |
the kernel-provided devtmpfs and all is good. |
48 |
|
49 |
But it's your choice, and that's great, but please be aware of the |
50 |
tradeoffs you are choosing, and again, my worry about using a |
51 |
/sbin/hotplug executable is real and should be resolved. |
52 |
|
53 |
What specifically is your objection to udev today? Is it doing things |
54 |
you don't like? Too big? Something else? |
55 |
|
56 |
thanks, |
57 |
|
58 |
greg k-h |