From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 21:15:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97DC8106564A for ; Sat, 18 Feb 2012 21:15:56 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2258F8FC08 for ; Sat, 18 Feb 2012 21:15:55 +0000 (UTC) Received: by werm13 with SMTP id m13so3975494wer.13 for ; Sat, 18 Feb 2012 13:15:55 -0800 (PST) Received-SPF: pass (google.com: domain of bf1783@googlemail.com designates 10.180.86.134 as permitted sender) client-ip=10.180.86.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bf1783@googlemail.com designates 10.180.86.134 as permitted sender) smtp.mail=bf1783@googlemail.com; dkim=pass header.i=bf1783@googlemail.com Received: from mr.google.com ([10.180.86.134]) by 10.180.86.134 with SMTP id p6mr5993158wiz.0.1329599755231 (num_hops = 1); Sat, 18 Feb 2012 13:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=O/sN1CLV5AM7GJpsGHQR+sgTvHYAD1FUCWEbEy4mGsA=; b=AnoQPIB+CCU/sBqG2erErCM6eOtVeA4Kt/y5O1PmoIvAQ0Ay9Bngfjl0csgo6krIWf 1/rHP++Oayp+9mW38VKOu+lQ4/kd0iBOYfDIdwaLpacHiWbh+LJAUkE+IkEX+Bpd7cbH Sj2IV85W5jteLj6LfYkxDgR2iHx5VlpNge0qA= MIME-Version: 1.0 Received: by 10.180.86.134 with SMTP id p6mr4966574wiz.0.1329598201930; Sat, 18 Feb 2012 12:50:01 -0800 (PST) Received: by 10.180.126.69 with HTTP; Sat, 18 Feb 2012 12:50:01 -0800 (PST) Date: Sat, 18 Feb 2012 20:50:01 +0000 Message-ID: From: "b. f." To: freebsd-hackers@freebsd.org, Alex Goncharov Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 21:15:56 -0000 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.