LinuxSA Mailing list archives

  From: Alex Garner <linuxsa@bourbon.lynx.net.au>
  To  : tjcorkin@steadycom.com.au
  Date: Mon, 12 Apr 1999 14:57:26 +0930

Re: Passing Options to loadable modules

Just as a followup to this, the problem was exactly as I outlined, a syntax
error. I noticed when I was installing 4 ethernet cards into a linux box
last month that although you pass the following options to the kernel if
compiled into the driver  you specify them slightly different for a module
in /etc/conf.modules. I simply extrapolated when I learned with the cards,
and it of course didn't work!

The reason I bring this up is I've yet to find a good source of information
about /etc/conf.modules and /lib/modules/preferred/modules.dep Although
/usr/src/linux/Documentation/modules.txt goes into quite a bit of detail as
to HOW modules work, it lacks a fair bit on getting modules going with
respect to the options in /etc/conf.modules Has anyone found any good
reference yet?

Also, to explain my reference to things working in X, that was to point out
that my problem is not related to a /dev/cdrom symlink clash. If you run a
couple of cdrom's always specify your drives explicitly (/dev/hdc) rather
than using the /dev/cdrom symlink. The symlink is fine for single drive
systems. It never occured to me that some people might consider that the
GUI is part of the OS *shudder*. 

With regard to the comments about the /lib/modules/preferred link, I
recommend leaving it and using it. It is a good way of keeping different
modules for different kernels around, and it follows the tradition of
/usr/src/linux (this is a symlink to your current 'in use' kernel source
tree). The problem with my system (as explained) was only syntactic.

...But thanks for going into so much detail anyway. (I was only after that
one line of text!!)  I'm sure it will be of use to people on this list.
Getting modules working properly and effeciently can be a little tricky,
but is a much better than hardcoding your kernel.

At 13:45 12/04/99 , Toby Corkindale wrote:
>Alex Garner wrote:
>> 
>> I have an IDE cdrom (/dev/hdc) and a soundblaster cdrom running on the
>> soundblaster card IDE port (/dev/sbpcd). I have both running happily in the
>> same machine, one for data cds, and one for audio cds.
>> 
>> Both cdroms work fine for both data discs and audio discs, even in X.
>X doesn't affect your modules. It's just another userspace program like
>anything else. Only with graphics.
>M$ Windows uses different device drivers to M$ DOS, but under Linux the
>GUI is not part of the O/S.
>
>> 
>> The soundblaster cdrom is accessed via a loadable module. When a system
>> call for the drive occurs (eg `mount /dev/sbpcd /mnt/cdrom`) the module
>> starts to look for the drive with it's built-in auto probing sequence. Once
>> it finds it (after about 2 minutes) everything is fine. If I want to I can
>> pre-load the module and specify parameters manually `insmod
>> /lib/modules/preferred/cdrom/sbpcd.o sbpcd=0x230,1` and this works fine
>> without having to autoprobe, thus saving lots of time.
>You should be able to type merely
>insmod sbpcd sbpcd=0x230,1

>insmod usually does not require a path, since your modules should always
>be in the same place.
>If you can't, however, then I suspect either your modules path is odd,
>or your module probing on startup is not running and/or working.
>
>> 
>> A simple fix for this would be to compile the module as a driver into the
>> kernel, and specify the options at compile time OR pass the parameters
>> through lilo. However I would prefer to leave it as a module.
>If it's a module, you don't pass options thru lilo/loadlin - that's just
>for non-modular code.
>(I believe? Or does that still work?)
>
>> 
>> I want to know how to specify parameters so that when kerneld load the
>> module automatically, it looks for the soundblaster at 0x230 straight away.
>> 
>> I've tried a few variations on "options sbpcd io=0x230 type=1" etc etc in
>> /etc/conf.modules, but this just causes the module to dump out saying that
>> it couldn't locate the module.
>You're using the right file.
>Above you said you needed to do insmod ..blah.. sbpcd=0x230,1
>So, enter into conf.modules:
>options sbpcd sbpcd=0x230,1
>since modprobe will just pass the rest of the line onto insmod, and
>apparently sbpcd=0x230,1 is the correct option.
>However, the error that it cannot find the module is suspicious. This is
>not due to your options being valid or invalid. Coupled with your
>requiring a full pathname for your module suggests that something is
>astray. Check that depmod -a is being run on start up. Thats the line
>that says "Generating module dependancies" or something similar, on boot
>in redhat linux.
>Try typing depmod -a manually, and see if there are any error messages.
>
>I am always a bit suspicious of the /lib/modules/preferred link that
>redhat creates. Try removing the link and rerunning depmod -a, then
>modprobe sbpcd.
>Out of interest, can you modprobe anything else without putting a full
>path in?
>Have you recompiled your kernel using newer sources than the
>alan-cox-special-edition kernel that comes with rh5.2? I'm pretty sure
>you want to remove the 'preferred' link if so.
>
>Can anyone else explain the nature of that link?
>The kernel's are smart enough to work out their version number, and
>change into that directory to access modules, so why the preferred link?
>I guess you could create multiple zimages and multiple corresponding
>sets of modules - but anyone who's likely to do that would be capable of
>making and breaking links on their own.
>Is it redhat specific, or in all recent kernels?
>
>Yours,
>Toby
>
>> 
>> Any ideas?
>> 
>> Cheers
>> 
>> Alex!
>> 
>> --
>> Check out the LinuxSA web pages at http://www.linuxsa.org.au/
>> To unsubscribe from the LinuxSA list:
>>   mail linuxsa-request@linuxsa.org.au with "unsubscribe" as the subject
>
>-- 
>...Veni, Vidi, VC++. (I came, I saw, I kludged)
>> 
>> A simple fix for this would be to compile the module as a driver into the
>> kernel, and specify the options at compile time OR pass the parameters
>> through lilo. However I would prefer to leave it as a module.
>If it's a module, you don't pass options thru lilo/loadlin - that's just
>for non-modular code.
>(I believe? Or does that still work?)
>

-- 
Check out the LinuxSA web pages at http://www.linuxsa.org.au/
To unsubscribe from the LinuxSA list:
  mail linuxsa-request@linuxsa.org.au with "unsubscribe" as the subject