modutils-1.2.8 configuration file parsing not working as documented

modutils-1.2.8 configuration file parsing not working as documented

Post by Amy A. Lewi » Sat, 17 Jun 1995 04:00:00



Hiyas.

I've just moved from full-dress kernels to smaller kernels with module-loading.
I did this first with the 1.2.9 kernel and modutils 1.2.8, with no
configuration file (everything in the default places per the man page for
depmod/modprobe(8)). Then 1.2.10 appeared, and I recompiled (for other reasons,
actually).  For the 1.2.9 kernel I'd created the directory /lib/modules/boot
and put symbolic links to the things I wanted to load automatically.  With two
different kernel versions, I renamed that directory to boot-1.2.9, made a
boot-1.2.10 directory and put 'identical' links there (to the 1.2.10 subdir
instead of 1.2.9, of course).

And then I wrote the configuration file, /etc/conf.modules, with a single line
in it:
path[boot]=/lib/modules/boot-`uname -r`
According to the documentation, this should have worked; the paths not
mentioned should have retained their default values.

They didn't.

I load umsdos.o on boot.  The first time I went to reboot after making these
changes, I got a slew of "wrong version" and "undefined symbol" gripes in the
dmesg.  I almost tried to recompile; then I went and looked at the dependency
file in the 1.2.10 subdir.  It had two files mentioned--the two modules that
were in the directory specified by the configuration file.  Depmod didn't look
in the other default paths, it apparently decided that any 'path[xyzzy]='
command was the only place it needed to look.  Interestingly, it wrote the
dependency file (which can be specified in the configuration file with a
'depfile=' line) in the correct place.  At any rate, since depmod hadn't found
msdos, which is required for umsdos, modprobe died horribly in a firestorm of
dependency failures.

The obvious workaround for this is to read the man page, extract the set of
default paths for xyzzy in fs, net, misc, and scsi, and write the supposedly
default information into the configuration file (complete with typographical
errors on my part, of course).  I'm *irritated* (could you tell?).

Can someone with a deeper understanding of how modutils works find the code in
it that's supposed to parse the configuration file and give me a fix, so that
overriding one default doesn't wipe out all of them?

TIA

Amy!


 
 
 

modutils-1.2.8 configuration file parsing not working as documented

Post by Bjorn Ekwa » Sun, 18 Jun 1995 04:00:00



Quote:> Hiyas.
[...]
> And then I wrote the configuration file, /etc/conf.modules, with a single line
> in it:
> path[boot]=/lib/modules/boot-`uname -r`
> According to the documentation, this should have worked; the paths not
> mentioned should have retained their default values.

> They didn't.

Perhaps the man page was a bit unclear about this, but Jacques and I
had a long discussion about what would be the sensible behaviour.
We decided on removing all preconfigured paths if there were any
"path=" lines in /etc/conf.modules.o
In "depmod/config.c", around line 224 there is a comment about this.

If you would like to retain the pre-configured paths, just change
line 159 in "depmod/config.c":

-       int no_path_so_far = 1;
+       int no_path_so_far = 0;

Greetings,

Bjorn

 
 
 

modutils-1.2.8 configuration file parsing not working as documented

Post by Amy A. Lewi » Sun, 18 Jun 1995 04:00:00




>[...]
>> And then I wrote the configuration file, /etc/conf.modules, with a single line
>> in it:
>> path[boot]=/lib/modules/boot-`uname -r`
>> According to the documentation, this should have worked; the paths not
>> mentioned should have retained their default values.

>> They didn't.

>Perhaps the man page was a bit unclear about this, but Jacques and I
>had a long discussion about what would be the sensible behaviour.
>We decided on removing all preconfigured paths if there were any
>"path=" lines in /etc/conf.modules
>In "depmod/config.c", around line 224 there is a comment about this.

Thanks, Bjorn.  That's exactly what I wanted to know.  Can I suggest a couple
of things?  Check the man page--I don't think it's unclear, I think it may be
from a time when your decision was to preserve default paths.  Second--perhaps
the current real behavior could be changed?  To change all default paths
something like path[*]=, but if a particular tag is mentioned, only that tag
gets changed.

Because of the way the default paths are set up, it seems to me that the Path
Most Likely To Be Changed is [boot], which unlike the defaults for the other
tags, doesn't have an embedded `uname -r`.  It wouldn't surprise me if others
have encountered this problem (only maybe been less, err, *shrill* about it!
:-).

Thanks again!

Amy!