Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Feb 2012 20:50:01 +0000
From:      "b. f." <bf1783@googlemail.com>
To:        freebsd-hackers@freebsd.org, Alex Goncharov <alex-goncharov@comcast.net>
Subject:   Re: 8 to 9: Kernel modularization -- did it change?
Message-ID:  <CAGFTUwOJenGKO8nRv2AhFUo6so6Qnbw6mLyEt==daaqprZx5-g@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
Most of these questions are more suitable for the freebsd-stable or
freebsd-questions mailing lists, rather than freebsd-hackers.

Alex Goncharov wrote:
> What I see in 9 now is very confusing for me; e.g.:
>
> * Why 'snd_hda.ko' even exists, if the whole 'snd_hda' implementation lives in
>   'kernel' now?
>
>   If not the whole, why is it split between 'kernel' and 'snd_hda.ko'?
>

The implementation is not split between the kernel and the module: the
snd_hda components are redundant.  By default, most of the kernel
modules are built and installed, even those present in GENERIC, unless
one removes them from the build with MODULES_OVERRIDE or
WITHOUT_MODULES (see, for example, make.conf(5)).  This is because
users often build one or more kernels that may not have all of the
components that are in GENERIC.  You can easily remove the modules
that you don't want.

> * Why did 'snd' earn the honor to live in 'kernel', but 'linux.ko' did
>   not?

Because some people requested it, and no developer objected.
Different users have different requirements, and most people can find
parts of GENERIC that they don't want or need.  Fortunately, users can
easily build a custom kernel.  If you don't want to be bothered with
constructing a minimal custom kernel, but just want to remove a few
components from GENERIC, you could use a simple custom kernel
configuration like:

include GENERIC
ident MUTEGENERIC
nodevice sound , snd_es137x , snd_hda , snd_ich , snd_uaudio , snd_vida8233

See, for example, config(5).

>  * And what about CAM?
...
>     Should I now (in 9) have:
...
> atapicam_load="YES"
...
>     as I had in 8, or it's no longer necessary because of the above
>     extract from /usr/src/sys/amd64/conf/GENERIC?

If you are using ATA_CAM, then you should not be using atapicam.  I
suspect that an explicit discussion of this is missing from some of
the manpages because developers were planning to remove the old ATA
code, and didn't want to spend a lot of time rewriting those
documents, only to change or remove them later.  But this has been
mentioned several times on various lists, and is documented in
src/sys/conf/NOTES:

# ATA_CAM:              Turn ata(4) subsystem controller drivers into cam(4)
#                       interface modules. This deprecates all ata(4)
#                       peripheral device drivers (atadisk, ataraid, atapicd,
#                       atapifd, atapist, atapicam) and all user-level APIs.
#                       cam(4) drivers and APIs will be connected instead

The cd(4) driver in 9.0 should work adequately for most CDs, although
you may want to add some post-release fixes from 9-STABLE, like:

http://svnweb.FreeBSD.org/base?view=revision&revision=230014

...
> | I keep hoping that if I repeat this enough times that people will get
> | the word. :)  Because loading modules through loader.conf is
> | veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called
> | kld that will load the specified modules after disks are mounted. This
> | is at least an order of magnitude faster. Look for kld_list in
> | rc.conf(5) if you want the details, but the short version is that you
> | just do something like, kld_list="umass coretemp ichwd linux nvidia".
> | This is in all the -stable branches (including 7), is already in 9.0,
> | and will be in 8.3.
>
> I will use this -- thank you!

You should be aware that kld_list doesn't always work.  For example,
my Nvidia nForce MCP61 network adapter works with nfe(4) when I load
if_nfe.ko from loader.conf, but fails to function properly if the same
module is loaded via kld_list, spamming the console with messages
like:

"... kernel: nfe0: watchdog timeout (missed Tx interrupts) -- recovering"

when I attempt to establish a connection over it.

b.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGFTUwOJenGKO8nRv2AhFUo6so6Qnbw6mLyEt==daaqprZx5-g>