On Mon, Sep 22, 2003 at 07:58:27AM -0500, David Fleck wrote:
> On Sun, 21 Sep 2003, Sergey DoubleF Zaharchenko wrote:
> > On Sun, 21 Sep 2003 18:53:31 +0000 Sergey "DoubleF" Zaharchenko <[EMAIL 
> > PROTECTED]> probably wrote:
> > > Mostly the program which uses the device. For instance, vnconfig and
> > > mount will load the necessary modules because they are supposed to be
> > > run as root and expect to have the necessary priveleges. Why would a
> > > programmer make a mp3 player that would auto-load the sound module? An
> > > mp3 player should be portable and should not depend on such things as a
> > > kernel module. Moreover, the player is not supposed to run as
> > > root, which is required to load kernel modules.
> >
> > You should read kldload(2), etc. if you want to load modules in your program.
> 
> Thanks for the response - it helps shed some more light on things.  But I
> don't want to load modules for 'my' program - I'm far less interested in
> this from a development point of view than from a system admin. point of
> view.
> 
> Why, for instance, does my (4.6.2-RELEASE-p20) system have a nfs.ko kernel
> module, and a line in /boot/defaults/loader.conf to enable this module,
> but (apparently) no way to *use* the module?  If I compile a kernel with
> 'options NFS' uncommented in the kernel config file, the nfs module gets
> built into the kernel, and loading the module is pointless - however, if I
> comment out 'options NFS', the kernel can't compile because of missing
> symbols.  So I have a chunk of code that gets built by the makefile as a
> module, but can't be used as a module?  I find this all very unintuitive.

What do you mean "can't compile"?  I have built kernels without
'options NFS' before without any problems, and it certainly is supposed
to be possible to build a kernel without NFS support, and later load
the NFS code via the module.  AFAIK all the modules built can be used
as modules, otherwise, as you note, there wouldn't be much point in
having them as modules and the developers are generally not that
stupid.

In some circumstances it is necessary to have code built into the
kernel rather than loaded from the corresponding module, but these are
exceptions rather than the rule.

One example is the ipfw.ko module. All modules are built with a fixed
set of options and this module is built without 'options IPDIVERT'
which is required to used natd. So if you want to use natd you need to
have both 'options IPFIREWALL' and 'options IPDIVERT' in the kernel
config, while if you just want a firewall without NAT support you can
compile the kernel without either option and load the ipfw.ko module at
runtime.
Another example is if you want to boot from an NFS-mounted filesystem,
in which case you need NFS support in the kernel, since otherwise the
system canšt load any modules.



> 
> What seems to be happening during the kernel compile process is that a
> certain number of modules are always compiled, regardless of config file
> settings - the settings only determine if a given chunk of code makes it
> into the kernel itself.  If the module is compiled into a .ko file, and if
> the code isn't present in the kernel, then it can be loaded by kldload. Is
> this correct?

Yes, that is essentially correct.


-- 
<Insert your favourite quote here.>
Erik Trulsson
[EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to