On Mon, Jan 11, 2010 at 01:08:35AM -0600, Bruce Dubbs wrote: > jmsc...@setex.ipcallback.com wrote: > > On Sun, Jan 10, 2010 at 10:37:13PM -0600, Bruce Dubbs wrote: > >> jmsc...@setex.ipcallback.com wrote: > >> > >>> the standard output to /lib/udev/write_net_rules is > >>> caught and filtered by udevadm, so examining the env list to execve() > >>> seemed a bit more direct. > >> Where is standard output caught? I don't see it. After options, udevadm > > > > libudev/libudev-util-private.c, util_run_program(), line 238. > > > > from a causual reading of the source, looks like > > udevadm-test() eventually calls util_run_program() > > We may be running different versions of udev. I'm looking at 145.
bb4a557de1fcef2cbeefea8b8e7cb7938bb54760 udev-145.tar.bz2 7091aa1ec78fdb9247f3813d785bc4e9a03efd2b udev-config-20090523.tar.bz2 > > > getting late ... i'm sure it's something simple. > > mere matter of debugging. from a casual reading of the udevadm source, to me it appears the construction of the envp list to execve() is anything but simple. so far, the udev source i'm examining is consistent with the behavior i'm seeing, but i haven't hacked too deeply, since i'm trying to keep the lfs fs as pristine as possible. it appears only execve() invokes the script, so the environment would be created explicitly. i don't see any reference to the global **environ list or to any environment passed in main(), so i assume the environment is derived according some interaction with the rules file. before hacking too much further, i ought to readup on udevadm. unfortunately, my linux kernel building knowledge is way pre udev. > > I agree. I haven't heard of anyone else having the problem. > > -- Bruce hi-ho, hi-ho ... -j > > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-support > FAQ: http://www.linuxfromscratch.org/lfs/faq.html > Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
