]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
MFC r335652-r335654
authorkevans <kevans@FreeBSD.org>
Mon, 16 Jul 2018 14:38:57 +0000 (14:38 +0000)
committerkevans <kevans@FreeBSD.org>
Mon, 16 Jul 2018 14:38:57 +0000 (14:38 +0000)
commit82a02a0d4343c5686d5849ae3810a86569314c97
tree8f090f240131067fc69097e48d997398681971fc
parent48b307741f05f5b9bec629d9cd529d6afbee6994
MFC r335652-r335654

r335652:
config(8): Make 'env' files consistent with other file-accepting options

Previously, only one 'env' file could be specified. Later 'env' directives
would overwrite earlier 'env' directives. This is inconsistent with every
other file-accepting directives which process files in order, including
hints.

A caveat applies to both hints and env that isn't mentioned: they're
concatenated in the order of appearance, so they're not actually applied in
the way one might think by supplying:

hints x
hints y

Hints in x will take precedence over same-name hints in y due to how
the kernel processes them, stopping at the first line that matches the hint
we're searching for. Future work will flip the order of concatenation so
that later files may still properly override earlier files.

In practice, this likely doesn't matter at all due to the nature of the
beast.

r335653:
config(8): Flip the order of concatenation for `hints` and `env`

As previously noted, kernel's processing of these means that the first
appearance of a hint/variable wins. Flipping the order of concatenation
means that later variables override earlier variables, as expected when one
does:

hints x
hints y

Where perhaps x is:

hint.aw_sid.0.disable=1

and y is:

hint.aw_sid.0.disable=0

The expectation would be that a later appearing variable would override an
earlier appearing variable, such as with `device`/`nodevice`, device.hints,
and other similarly structured data files.

r335654:
config(8): part of patch disappeared, don't close ifp at the end
usr.sbin/config/config.5
usr.sbin/config/config.h
usr.sbin/config/config.y
usr.sbin/config/mkmakefile.c