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
[email protected]
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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
