On Mon, Jun 02, 2008 at 09:13:20AM -0700, [EMAIL PROTECTED] wrote: >Hello, Bernhard! [hey there. Replying on the ML, hope you don't mind] > >Please, tell me: do you test your code before you submit it?
occasionally, yes ;P In this case i did, see below. > >I put my modules into /usr/lib/modules. I set CONFIG_DEFAULT_MODULES_DIR to >that location. That's fine and the reason why we have that CONFIG. >I ran depmod. I got null modules.dep... Sounds odd. What revision are you using? Please use rev22215 or later *without* any patches. >I ran "ln -s . 2.6.25.2" in /usr/lib/modules. That way I simulated >/usr/lib/modules/2.6.25.2 being _so_ >necessary in depmod. I reran depmod. And regot null modules.dep! a symlink won't work, make that a hardlink (and no, i won't change it to accept symlinks since then it would potentially walk down the source/ dir. No way). >Ah. recursive_action() can not resolve symlinks... It can but we don't want that. See above. >But I just can not guess what parameters to pass in my situation?!! make a hardlink or patch the c code or use the perl script or use the sh script :) > >Can you reproduce the situation? I imagine that a symlink will not work, yes. >Can you answer all the following questions? > >1. Why two cycles? It was a design-decision that helped collecting all full paths to modules. I then had all info to emit the module right on the spot when matching a dependency. Somehow i thought that i have to protect against modules with identical filenames living in different directories, but fortunately there are no such occurances and this is unlikely to change (so i dropped the gather-only walk a few days ago). >2. Why append 2.6.25.2 or specific kernel version? well, that's what the manpage of depmod says and we want to have a drop-in replacement. >3. Why bloaty code is better? Where did i say that? >4. Why reject and even not mention other people contribution? vda added your shell-script. I didn't look at nor used any code from you for depmod. What do you mean, specifically? > >--- > /* modprobe allegedly wants dependencies without duplicates, i.e. > * mod1: mod2 mod3 > * mod2: mod3 > * mod3: > * implies that mod1 directly depends on mod2 and _not_ mod3 as mod3 is > * already implicitely pulled in via mod2. This leaves us with: > * mod1: mod2 > * mod2: mod3 > * mod3: > */ > >Wrong! >modprobe has no recursive lookup. If it has been told to load mod1 it will >lookup for JUST mod1: line in modules.dep. Are you sure? All of my modprobes load the deps in order, but see below. >What you name ENABLE_FEATURE_DEPMOD_PRUNE_FANCY is (the only) way to generate >useful modules.dep! nope. The non-pruning one works just fine for me. > >Can you unload ALL sound modules (including snd and soundcore) and then reload >snd-pcm-oss one? yes, loading snd-pcm-oss is loaded fine for me with both modprobe from module-init-tools as well as our modprobe. Tried it, works flawlessly. Could it be that you have a stale link to some old or broken modprobe on your box? What version are you using? As mentioned a few minutes ago, please also send me the debugging-output of modprobe and make sure that you really use the insmod and modprobe that you think you are using. TIA, _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
