mdev with hda's

[David Henderson]

On 05/11/2011 10:53 AM, Harald Becker wrote:
>   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.

I figured that you were joking when using the asterisks in your reply 
based on how you were using them.  It actually caused me to laugh too. :)

>> 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
> below).
>
>
>>   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).
>
> --
> Harald
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox

I agree that mdev should be lightweight because of where and how it's 
used.  For various reasons I actually favor mdev over udev, but one is 
because it does provide a very simple interface while giving the user 
the ability to customize what happens when processing devices in 
whatever way they want, when using external scripts.  The only problem I 
have is that in one situation I get 2 mdev environment variables and in 
the other I get ~14 (of which are not all used).  To make up for the 
lack of ~12 variables would require extensive script coding when most of 
those variables should already be accessible by mdev or can be figured 
out relatively easily based on rule matching.  I'll post more on this in 
the other follow-up reply to this thread.

Dave