mdev

[Rob Landley]

On Wednesday 15 April 2009 00:56:25 Vladimir Dronnikov wrote:
> > If that's what you want.  The point of mdev -s is speed and simplicity.
> >
> >> and "mdev without -s" should be renamed to "hotplug" and just be
> >> hotplug helper.
> >
> > The system hasn't defaulted to calling an /sbin/hotplug helper for years
> > now. You have to specify a program in order for it to do so at all.
>
> I know that. But it is reasonable default which works out-of-box as
> soon as root fs is mounted.

Your init scripts have to do it.  The kernel won't.  (It used to, and it was 
intentionally removed, because udev is a daemon and uses netlink, and the 
guys who write sysfs are the same ones who write udev and think of it as the 
only user.)

My point is your init scripts can just as easily echo /sbin/mdev 
as /sbin/hotplug, so renaming it doesn't buy you anything.

> > There's also a netlink option, which was posted to the list long ago and
> > which I could dig up if there's interest.  It does exactly the same
> > thing, it just means you need mdev running as a daemon like udev, which
> > generally embedded systems don't want because it takes up memory.
>
> BB is not for embedded people only, I guess.

The point of busybox is to be small and simple.  If you don't want small and 
simple, there are other implementations of everything busybox does.

> The reason I'm drifting 
> from udev to mdev is that the former has way extensive configuration
> and is of 500Kb (statically linked) in size (counting helpers like
> ata_id and friends).

I'm all for more people using mdev, I just don't want to see _it_ winding up 
with extensive required configuration and being 500k. :)

> > The purpose of mdev was always to populate the /dev directory.  That's
> > it. You can wrap it in a hotplug script if you like, but that's not part
> > of the scope of what it's trying to do.
>
> OK. I see. But it is now capable of loading firmware. Why to not load
> modules. It is one of intrisic rules, I hope.

Its scope is drifting.  The problem with turning into a generic "hotplug" 
daemon is that not everything hotplug does is obvious (firing off a 
filesystem viewer for thumb drives, firing off a picture viever for cameras, 
etc), and if you bolt everything it _might_ do in as C code, it'll never stop 
growing.

Looking at it now, the SEQNUM infrastructure has no config symbol, even though 
mdev -s will never need it and lots of other stuff won't either.

The point of the config file's ability to launch arbitrary scripts was so the 
C code wouldn't have to grow additional abilities.  Right now it's got got 
firmware loading.

You're proposing to add module loading.  Did you look at the program I linked 
last message, and notice the large about of parsing it was doing to match 
domain specific vendor ids for various bus types?  Is the kernel doing that 
these days so you don't _need_ to add it to mdev, or are you proposing adding 
all that to mdev?

> > I started looking at your patch, then I started looking at the mdev.c
> > code it applies to, and...
>
> The patch has nothing to do with mdev.c coding style.

I know.  Didn't say it was your fault, just that I should do some cleanup on 
it if I'm going to take an interest.  Starting with an #ifdefectomy...

> Regards,
> --
> Vladimir

Rob
-- 
GPLv3 is to GPLv2 what Attack of the Clones is to The Empire Strikes Back.