Re: [gentoo-dev] Stability of /sys api

[Greg KH <gregkh@gentoo.org>]

On Tue, May 15, 2012 at 01:55:23AM -0400, Walter Dnes wrote:
> On Mon, May 14, 2012 at 06:23:36PM -0700, Greg KH wrote
> 
> > So you need to implement stuff such that you are not dependant on the
> > bus type.  If you see a new disk, act on it, it's that simple.
> > 
> > But note, please do not be automounting disks from uevents directly.
> 
>   After some more Google-searching. it looks like the "official
> channels" way is via /etc/mdev.conf.  Note that this is on a system with
> busybox[mdev] and no udev.  /etc/mdev.conf has a rudimentary set of
> "mdev rules" abilities, and most importantly, it can also call external
> executables (scripts/programs/whatever).  On my mdev based machines...
> 
> $ cat /proc/sys/kernel/hotplug
> /sbin/mdev

Oh my, don't do that.  Please.  It will slow your machine down, and on
some systems, and devices, cause fork-bombs causing your box to come to
a crawl and potentially die.  There's also ordering issues that the
called program needs to resolve to get things right that add lots of
logic and slowdowns at times.  I really want to get rid of that entry
and option from the kernel entirely, but need to keep it due to legacy
systems and API issues.

But really, don't do that, it's not a good idea at all.

> > 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.  Why not just fork udev from then and go
> > forward from that?  What exactly are you not liking in udev that makes
> > you want to get rid of it so badly?  What is it doing that bothers
> > people so much?
> 
>   Unfortunately, I am not a C programmer, so forking udev is only a
> dream.  As Maxim has pointed out, mdev does what most people need.

As does udev.  And udev is faster, and I'd bet, the same size.

> The busybox people do the maintenance.  Given their target audience
> (embedded and lightweight systems), we can be certain that mdev won't
> grow into a monstrosity.  Even if I could do it, why reinvent the
> wheel?  We have a perfectly usable alternative right now in mdev.

mdev is the reinvention, but hey, if you want it, that's fine.  Embedded
and "lightweight" systems don't even need mdev or udev, they just use
the kernel-provided devtmpfs and all is good.

But it's your choice, and that's great, but please be aware of the
tradeoffs you are choosing, and again, my worry about using a
/sbin/hotplug executable is real and should be resolved.

What specifically is your objection to udev today?  Is it doing things
you don't like?  Too big?  Something else?

thanks,

greg k-h