svn commit: r277204 - head/sys/amd64/conf
Warner Losh
imp at bsdimp.com
Fri Jan 16 18:48:30 UTC 2015
> On Jan 16, 2015, at 11:43 AM, Adrian Chadd <adrian at freebsd.org> wrote:
>
> On 16 January 2015 at 09:57, Warner Losh <imp at bsdimp.com> wrote:
>>
>>> On Jan 15, 2015, at 6:23 AM, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:
>>>
>>> On Thu, Jan 15, 2015 at 12:42:07AM +0000, Warner Losh wrote:
>>>
>>>> Author: imp
>>>> Date: Thu Jan 15 00:42:06 2015
>>>> New Revision: 277204
>>>> URL: https://svnweb.freebsd.org/changeset/base/277204
>>>>
>>>> Log:
>>>> New MINIMAL kernel config. The goal with this configuration is to
>>>> only compile in those options in GENERIC that cannot be loaded as
>>>> modules. ufs is still included because many of its options aren't
>>>> present in the kernel module. There's some other exceptions documented
>>>
>>> Are you sure?
>>> I think defining UFS options in kernel connfig affect to module too.
>>> When I define this options in kernel config (w/o options FFS) I got
>>> ufs.ko with this SU, quota, acl etc.
>>
>> While one could set options in the kernel to affect the ufs.ko build,
>> there’s not a universal ufs.ko that can be loaded easily that switches
>> between the different types of options. You can create modules
>> that do this, but that’s a very very different problem than the one I
>> want to solve, namely you get the same[*] functionality having
>> device fred in the kernel config as kldloading fred.ko. So rather than
>> bite off that problem also, I’m opting for simplicity.
>>
>>>> +options SOFTUPDATES # Enable FFS soft updates support
>>>> +options UFS_ACL # Support for access control lists
>>>> +options UFS_DIRHASH # Improve performance on big directories
>>>> +options UFS_GJOURNAL # Enable gjournal-based UFS journaling
>>>> +options QUOTA # Enable disk quotas for UFS
>>>
>>>> +options SYSVSHM # SYSV-style shared memory
>>>> +options SYSVMSG # SYSV-style message queues
>>>> +options SYSVSEM # SYSV-style semaphores
>>>> +device agp # support several AGP chipsets
>>>> +device random # Entropy device
>>>> +device padlock_rng # VIA Padlock RNG
>>>> +device rdrand_rng # Intel Bull Mountain RNG
>>>> +device vlan # 802.1Q VLAN support
>>>> +device tun # Packet tunnel.
>>>> +device gif # IPv6 and IPv4 tunneling
>>>
>>> This is loadable too.
>>
>> True
>>
>>> And please include:
>>>
>>> NETMAP
>>> NFS_ROOT
>>
>> OK.
>>
>>> IEEE80211_DEBUG
>>> IEEE80211_AMPDU_AGE
>>> IEEE80211_SUPPORT_MESH
>>> AH_SUPPORT_AR5416
>>> AH_AR5416_INTERRUPT_MITIGATION
>>> ATH_ENABLE_11N
>>
>> These are already the default for the ath or wlan modules, if I’m reading things correctly.
>
> Nope.
It’s simple to add any of the last 3 to modules/ath, but I see your point.
> The other half of this problem is where some modules (did? do?)
> populate an opt_wlan.h with their own options. Some modules did this
> with the inet option.
You might thing that, but you’d be behind the times. The IEEE options
are centralized, as are the INET options.
> When I've done what you're doing, I end up having these options in my
> minimal config file so opt_xxx.h is correctly populated. That way when
> I point SYSDIR (or whichever variable it is) at the configured kernel
> directory with the opt_xxx.h files, it all works out correctly.
Yea, that’s a different issue.
> (I still think we shouldn't be relying on "defaults", but should ship
> the opt_xxx.h files or something to derive the opt_xxx.h and makefile
> config bits so things like external module building is possible
> against a kernel. Or, we just kill all module options that change
> behaviour/ABI of things in an incompatible way.)
Options aren’t supposed to change KBI. Some do, and that’s unfortunate.
But don’t turn this into a rant on how sub-optimal the opt_XXXX.h
intersect with modules. That’s another set of problems to solve.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20150116/4e356a61/attachment.sig>
More information about the svn-src-head
mailing list