Bug 182213 - kernel configuration doesn't honour nooption syntax as defined by config(5)
Summary: kernel configuration doesn't honour nooption syntax as defined by config(5)
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 9.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-18 20:40 UTC by pl
Modified: 2018-08-03 02:48 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pl 2013-09-18 20:40:00 UTC
I'm building a custom kernel based on the GENERIC kernel configuration. Because I'm using a VPS I don't need many of the options & devices so these get disabled. While building the kernel I get the following error:

config: /usr/src/sys/amd64/conf/SECKERNEL:16: syntax error
*** [buildkernel] Error code 1

Line 16:

nooptions       UFS_ACL, UFS_DIRHASH, UFS_GJOURNAL

If I change line 16 to its own block like so it'll work:

nooptions       UFS_ACL
nooptions       UFS_DIRHASH
nooptions       UFS_GJOURNAL

However, this goes directly against the definition in the config(5) manualpage:

     nooption name [, name [...]]
     nooptions name [, name [...]]

The reason I suspect a bug is because the 'nodevice' directive does behave as expected.

How-To-Repeat: Use the following kernel configuration file and try using "make buildkernel":

## Start of config
include GENERIC
ident TESTKERNEL

nooptions UFS_ACL, UFS_DIRHASH, UFS_GJOURNAL
## End of config
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:54 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 2 Kyle Evans freebsd_committer freebsd_triage 2018-08-03 02:48:20 UTC
Hi,

This was fixed with r277567 on 2015/01/23 by will@. The fix appears in all 11.x releases, but was not merged to the stable/10 branch at any time.

It could be trivially MFC'd to stable/10. Please feel free to drop a comment if this is desired in stable/10 before it goes EOL at the end of October.