mdev with hda's

Harald Becker ralda at
Wed May 11 14:53:53 UTC 2011

 Hallo David,

just a quick reply, may be later on more ...

> Harald, I apologize if placing asterisks around those words come off
> as offensive ...

I apologize! As I sometimes like to be a bit satirical, may be
misinterpreted. Sorry for this. I didn't want to criticism your asterisk
usage ... my indention was more to some kind of joke based on our
previous discussion ... joking on my failure to get your question right.
Sorry again, if that joking got lost due to translation.

> My question at this point would be why would the kernel then pass the
> shell environment variables when being called to handle hda devices
> (as opposed to just giving the MDEV and SUBSYSTEM variables only - the
> bare mdev enviroment), but pass just the kernel variables without
> shell environment variables when handling sda devices - a robust mdev
> environment?  This doesn't make any sense - why would the kernel
> involve the shell at one point and not in another?  Or perhaps, why
> does 'env' produce one environment including the shell variables and a
> completely different set of variables (without shell variables) in
> another?  It would make more sense that instead of passing shell
> environment variables in either scenerio, to just pass what mdev
> variables are configured and nothing else.  After all, if I want the
> shell environment variables, I can capture and process that
> information from within the script itself.  If I'm after the mdev
> environment, those are the values I'd be interested in and no others. 
> Also see below.

You are right. Based on the environment content it looks that something
suspicious is going on ... but it doesn't seem to me, that this origin
in mdev. May be mdev could/should contain extra code or workarounds to
deal with the trouble you revealed, but the current implementation of
mdev choses to be simple and lightweight, the Busybox philosophy (see

>  Is the mdev code base based on udev or completely from scratch?

IMHO mdev is a lightweight implementation of the function required for
dynamic device file creation. It is neither based on the source of udev
nor claims to be a full or compatible replacement of udev, else it could
have been named udev within Busybox. mdev tries to do only the bare
minimum required to do it's job. Where as udev is a big part of code,
that uses different approaches and goals ... and may be contain code
parts for information retrieval that let mdev out to be done in the
helper scripts. That simplicity is the reason for it's compactness and
minimalistic resource usage ... seems that most users do not have
troubles or at least can live with those.

... but you are right. It looks to me, that there is something
suspicious with environment setting ... needs to be investigated ... but
it doesn't seem to origin in mdev ... may be some extra code can be
added to deal with (I'm neither the creator nor maintainer of mdev, nor
an hotplug expert).


More information about the busybox mailing list