Harald, I apologize if placing asterisks around those words come off as
offensive - it surely wasn't my intention. In fact, I intentionally
didn't bold or underline for fear that it would be taken as aggression,
so I tried using asterisks to show emphasis. And the only reason I did
that was to prevent a misunderstanding that seemed like it was already
being manifested based on the post and response being:
post (me):
"To my amazement, it appears that the actual shell environment is being
exported and not the mdev environment. Has anyone else encountered this
or is this a bug with busyboxes mdev?" ... "At this point, I'm obviously
working solely with mdev and not my script to process hda devices."
reply (you):
"... or in other word's: The only idea I got from your description is,
it can't be a a problem of mdev ... sorry ... so, give exact example,
please."
As you can see, the post is saying that "I think there *is* a problem
with mdev", but your reply says that "I do *not* think there is a
problem with mdev" - a contradiction of one another. I thought you
might have misread the post and we were once again going in two
different directions. I emphasized those words so that they could not
be misread, not to offend. I also tried to use smilies in the reply to
indicate the overall tone of my response as not being angry. Plus some
communication isn't conveyed very well in written format since body
language and tone of voice can't be seen or heard. In other words, I'm
fairly certain that everyone in here is working towards a resolution and
is most likely conveying their thoughts in a non-aggressive way, it's
just that translation and/or cultural differences may be adding
additional complication where none truly exist. After all, it's not
very beneficial to anger the ones that are giving you help. :)
On 05/10/2011 06:16 PM, Harald Becker wrote:
Hallo David!
The script you provided does the exact same thing as "@env>>
/tmp/parent2" (confirmed via output), so I'll include that at the
bottom of this email.
Ok, you didn't gave the exact information I expected, but I'm going to
get an idea about your trouble ... (see below)
Apparently I'm missing what information you're asking for. :) If you
were just looking for the output of your script, the "@env >>
/tmp/parent2" produced the exact same output as I've confirmed by
visually comparing the output of both methods. What information are you
looking for specifically?
... or in other word's: The only idea I got from your description is, it
can't be a a problem of mdev ... sorry ... so, give exact example,
please.
No, what I'm saying is ...
Keep cool, I didn't expect you being an "idiot". That is the reason, I
asked for more information (was just satirical provocation with that
statement). As you *have* some kind of trouble, there *has to be* a
problem ... but not everybody use the same description for the same kind
of thing, and not every trouble origins at the expected place.
This response should have just been taken as two co-workers talking
casually in a hallway. Once again, no offense was intended. I'm going
to assume there's a problem in translation instead of being called an
"idiot". lol
it looks like it *is* a problem with mdev because *no* scripts are
being called *at all*, (...)
Until the output between the two types of devices become standard by
mdev, I can't call any script as the information will be accessible to
one, but not the other.
You are missing the fact, that mdev is not the only process in the
execution hierarchy and environment variables are passed trough from
parent to child processes. So the real problem needs indeed a bit more
of differentiating, which hasn't been revealed before you gave more
information!
... so lets clarify your problem first:
- Your trouble is *not* due to any differences in environment variable
passing between direct execution of 'env' in mdev or script ... that's
what I understood from the starting of your question.
Correct, there is no problem running 'env' from mdev directly or via a
script. See below for continued response to the mdev environment variables.
- Your trouble is because of the differences in environment settings
between hda and sda devices ... am I right now?
Just to be on the same page, not environment settings, but the
environment variables and values are different between internally and
externally attached devices.
... now some quick trouble analyzes:
- You are right, that output shows environment differences between hda
and sda (fact).
- Quick look into mdev source shows, that only two environment
variables are set/modified by mdev itself. Those variables are MDEV and
SUBSYSTEM. Other variables get just passed on from the caller of mdev.
(fact - if I do not have tomatoes on my eyes)
- Investigation of your output about MDEV and SUBSYSTEM variables show
those variables are set correct for hda and sda devices. (fact - or I'm
wrong about principle of mdev operation)
agreed about the MDEV and SUBSYSTEM variables
- As mdev only modifies variables MDEV and SUBSYSTEM and those look
correct, your trouble doesn't look like wrong behavior of mdev. (right?)
See below for more information.
- As environment shows major differences between hda and sda devices, we
need to look a bit closer, where do those differences come from. (right?)
- So who is the caller of mdev? If mdev is called as a hotplug handler,
the caller of mdev is the kernel ... or to be correct a kernel thread.
- And here we are at the point of difference. Depending on the kind of
device the hotplug handler (mdev) is called from different kernel
threads. (fact - as far as I understand kernel behavior)
- As mdev passes environment variables from it's calling parent and only
modifies the variables MDEV and SUBSYSTEM, the differences in
environment setting originate in different kernel threads. (right?)
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.
- As this is the Busybox mailing list, the right place for mdev
questions, but the origin of different environment setup seam to come
from the differences in kernel threads, further questions need to be
forwarded to the Linux kernel guys.
Did I got that right now?
BTW: I told you about unreliability of device information extraction
from kernel. This is exactly one of those cases. Different type of
device and the kernel doesn't reliably provide the expected set of
informations. Here we have the difference between device types, but
formerly this information even changed for the same device between
kernel versions.
See below
If anybody can tell about how to reliable get all that device
informations, someone should be able to modify mdev to reliable setup
all expected environment variables. Meanwhile it seams the best to me,
to keep on passing the kernel threads environment to the called hotplug
helper script. Which is what mdev does. The helper scripts needs to deal
with the differences in environment settings between device types.
That's why there exist different helper scripts for scsi, ata, usb
devices, etc. ... or big cases on those device types in an even
complexer helper script.
Sorry, that I can't provide a solution for your trouble.
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
So here is another interesting discovery. It appears that mdev is able
to create the device files for hda's even if the user decided to execute
a script instead of the internal calls by mdev (e.g. ">/dev/disk/%1" in
mdev.conf). So, why would mdev not also, by default, include the MAJOR
and MINOR variables in its environment output - after all it has to have
those values to be able to create the device file, so why not include
them in the env output? And based on certain information, some more of
the environment can be figured out and passed by mdev. For example, if
mdev matches the (s|h)da lines in the mdev.conf file, that means that
mdev can also pass other information such as PATH, ACTION, PWD, and
DEVNAME. This leaves only DEVTYPE, DEVPATH, SEQNUM. I'm not sure if
all (s|h)da's report the DEVTYPE as 'disk' (being as how they can be an
hdd, flash, ssd, etc), but that value might be able to be passed too.
DEVPATH is part of the sysfs so that information is present irregardless
of mdev processing it or not so it's part of the system that just
doesn't get processed by mdev. Thoughts?
Regarding the inability to reliably parse information from the kernel, I
still have to fall back to the reasoning that udev doesn't have a
problem parsing information reliably while mdev does. If I use a common
distro, the same devices that fail under mdev are picked up without
problems using udev. If I understood C or C++ better, I'd give a look
at the source code to see if I could figure it out. Is the mdev code
base based on udev or completely from scratch?
Dave
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
