Date: Fri, 16 Jan 2015 11:48:25 -0700 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, src-committers <src-committers@freebsd.org>, Warner Losh <imp@freebsd.org>, Slawa Olhovchenkov <slw@zxy.spb.ru> Subject: Re: svn commit: r277204 - head/sys/amd64/conf Message-ID: <A01F4A0B-E7F4-464B-91F4-ACB055A36435@bsdimp.com> In-Reply-To: <CAJ-Vmon1upJhjuAY8U8y376cxcqDwaVEu%2BBeOTDX5pp4TDsD1A@mail.gmail.com> References: <201501150042.t0F0g7Um018059@svn.freebsd.org> <20150115132303.GA245@zxy.spb.ru> <368B22F3-5607-46F8-B8D2-13CA59E94861@bsdimp.com> <CAJ-Vmon1upJhjuAY8U8y376cxcqDwaVEu%2BBeOTDX5pp4TDsD1A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > On Jan 16, 2015, at 11:43 AM, Adrian Chadd <adrian@freebsd.org> wrote: > > On 16 January 2015 at 09:57, Warner Losh <imp@bsdimp.com> wrote: >> >>> On Jan 15, 2015, at 6:23 AM, Slawa Olhovchenkov <slw@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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUuVz6AAoJEGwc0Sh9sBEAD1AQAM5AEyXxnOdjdQYyZgszjUQ7 +ElALFd8JAeALikfFBMSOBRU4bjA7btAEUfHpE3Lr1loJXHhxv0C4DWoVGfl0yQH HQr+Z6bFP9skPFwmwlGDggLwKrbZ0s38aDfHWe4hfcC4NwwHZKkzAz2DH54kn2al Q6ItPbu+rc3pZEYmmiiEu1zJxCDvSGtHzHuLHBsJZYNNm2W7pP8KvoFBf+qXxtNE s3LtSlx/waoZOcpRwOD3zmkb0yEU5h9M6LCo1Jdw9XyTBGMn0VlTWIMIjYOFJGcl mcR+mSyIW6FvgiHO9XuRyDiyRT/KeIxcLGjNKwiEoAuQGtyfVnnwQRHz1Jlm8MRe /gXTaY0dGx4/bgsR2CP+TfW8a6AsY8oPzLMP6FktSk5M+sdgH9QfITJMtY2yjaPP +2YG1Yh1GlbAUrW6ApGxRL9rg2dD5fPhVfmJHaDShQGp4p8L6O7fV5AIW26fqQFw o6gg57XPXct6CVpPmGudbPGfQQF4+lpaCoQjRmrLpOTkh/hZXUEvfMZH9eyQd8SE 3bjYWoD+RFLuwMy1EgGHYD6Pj8evq60Dxp+1Ihm5ZukvKfR0r9e9AnP6aIogFp7z ZPSemgSckunu3glcL18Bb6CzRZn6lpHeZ/vL1PHXDqAFCsnrVVPhcKYNiEOf3T3w HcOSjOTYDivsiOHPGIcz =SI4C -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A01F4A0B-E7F4-464B-91F4-ACB055A36435>