Date: Fri, 17 Feb 2012 23:30:35 -0500 From: Alex Goncharov <alex-goncharov@comcast.net> To: Doug Barton <dougb@FreeBSD.org> Cc: sendtomatt@gmail.com, rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? Message-ID: <E1RybwR-000JTv-UD@hans3> In-Reply-To: <4F3EFB70.5000102@FreeBSD.org> (message from Doug Barton on Fri, 17 Feb 2012 17:14:24 -0800) References: <CAOjFWZ6WM1bLEwaBiUE50Gj4MrwxefDWFb85ecRtYkSDuZ0erg@mail.gmail.com> <mailpost.1329495670.7246668.67851.mailing.freebsd.hackers@FreeBSD.cs.nctu.edu.tw> <4F3E8225.9030501@FreeBSD.org> <E1RyRKJ-000Ioa-Ec@hans3> <4F3E8C26.3080900@FreeBSD.org> <E1RyRq0-000Iqy-3l@hans3> <4F3EA5F2.9070804@gmail.com> <E1RyTZo-000J0R-0Y@hans3> <4F3EAE5F.6070903@gmail.com> <E1RyUv6-000J5e-0E@hans3> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
,--- You/Doug (Fri, 17 Feb 2012 17:14:24 -0800) ----*
| I think the question is not, "What should be in the kernel?" but rather
| "What should be on by default?" *How* those things are provided is a
| different question.
|
| One could argue that an intelligent installer combined with a more
| modular kernel would be the right answer.
An intelligent installer: anybody can start coding whatever he wants,
but from my perspective this is the last thing that FreeBSD is in need
of. The old installer that brought me to FreeBSD in the year 2004,
was doing its job all right and I liked it more than the "more
intelligent" installers I had used with other OSes. Once you learned
it, it was straightforward and efficient. With deficiencies, but
nothing that could not be resolved by rebooting the system. "Once you
learned" is key -- FreeBSD is the environment you want to learn, it's
pleasant to learn, and this is a significant part of its attraction.
Keep learning and soon "you" won't need an intelligent installer. In
short time, "you" may not need any installer at all.
Modular kernel: again, to a large extent, this is more about learning
and comprehending the OS than about the sizes and bootup times. What
I saw in FreeBSD 7 and 8, about the kernel and modules, was
transparent and logical: the basic devices would be a part of the
'kernel', and the nice-to-haves, e.g. for the sound, would be
optionally loaded (e.g. through loader.conf).
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'?
* Why did 'snd' earn the honor to live in 'kernel', but 'linux.ko' did
not?
I can live without sound, but if the Linux compatibility were not
available, I suspect that all my systems would lose FreeBSD
immediately. Not to have a well working Flash plugins is
unacceptable (for me) today.
So, why do I have to say 'linux_enable="YES"' in rc.conf and load
linux.ko to get this functionality, while all this stuff comes in the
'kernel',
kldstat -v | grep snd_
253 pci/snd_hda
252 hdac/snd_hda_pcm
251 pci/snd_via8233
250 pci/snd_ich
249 pci/snd_es137x
-- with a variety of cards. All of them, you will hardly find at
the same time on any machine.
* And what about CAM?
kldstat | grep cam
2 1 0xffffffff81467000 5570 atapicam.ko
Is having a working CD less or more important than a potential for
five types of a sound card?
Compare:
----------------------------------------
uname -sr; grep -i cam /usr/src/sys/amd64/conf/GENERIC
FreeBSD 8.2-STABLE
device aacp # SCSI passthrough for aac (requires CAM)
----------
uname -sr; grep -i cam /usr/src/sys/amd64/conf/GENERIC
FreeBSD 9.0-STABLE
options ATA_CAM # Handle legacy controllers with CAM
device ctl # CAM Target Layer
device aacp # SCSI passthrough for aac (requires CAM)
----------------------------------------
Should I now (in 9) have:
----------------------------------------
grep -i cam /boot/loader.conf
=>
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?
I really don't know -- please tell me somebody. I can, of
course, comment out the 'atapicam_load="YES"' line in loader.conf,
reboot and see what happens, but I'd prefer to understand it
without or before the experimentation.
| 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!
But again: should 'atapicam' be in 'kld_list' (or loader.conf), now that I see
new CAM things in GENERIC?
| Obviously you have to have everything in kernel and/or loader.conf
| that's necessary to get your local disks available, and the system to
| the point where it can start running rc. But everything else can go in
| kld_list.
Right, and one has a flexible control over the modules, resulting in
easier tuning and experimentation.
-- Alex -- alex-goncharov@comcast.net --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1RybwR-000JTv-UD>