Quoting John Baldwin <j...@freebsd.org> (from Fri, 11 Feb 2011 07:51:52 -0500):
On Friday, February 11, 2011 4:30:28 am Alexander Leidinger wrote:
Hi,
during the last GSoC various FEATURE macros where added to the system.
Before committing them, I would like to get some review (like if macro
is in the correct file, and for those FEATURES where the description
was not taken from NOTES if the description is OK).
If nobody complains, I would like to commit this in 1-2 weeks. If you
need more time to review, just tell me.
Here is the list of affected files (for those impatient ones which do
not want to look at the attached patch before noticing that they are
not interested to look at it):
Hmm, so what is the rationale for adding FEATURE() macros? Do we
just want to
add them for everything or do we want to add them on-demand as use cases for
each knob arrive? Some features can already be inferred (e.g. if KTR is
The non-answer is: IMO we want to add as much as needed. See below for
an explanation.
compiled in, then the debug.ktr.mask sysctl will exist). Also, in
the case of
KTR, I'm not sure that any userland programs need to alter their behavior
based on whether or not that feature was present.
The main goal was to have an easy way (e.g. not a lot of parsing)
without sideeffects (e.g. autoloading of kernel modules) to query if a
feature is available. Regarding this, there is no need to have one for
KTR.
The 2nd goal is (as you know, as we discussed it in the beginning of
the GSoC) to be able to hide a feature administratively (I plan to
commit the userland part regarding this last). You can not do this
with sysctl, so for me adding a FEATURE for KTR provides more
possibilities.
I see a use case for this in KTR, an app may see if it is there and
start some tracing based upon it (and it could be adminsitratively
prohibited by hiding the presence), or there could be a sanity check
in a script which prevents some tracing-setup to happen if it is not
there (or administratively hidden).
In general I do not want to decide if something makes sense for an app
or not, as I do not think I can come up with all possible use cases
(possibilities instead of policies). As such it makes sense to add
more FEATURE macros to the tree than what we have ATM. If used
correctly (via the to be committed userland part), this may make the
life of some people more easy.
As a 3rd point (attention bikeshed ahead), having everything as a
FEATURE would give an uniform way of listing what is available or not
(with the benefit to administratively hide parts of it). Needless to
say that this would reduce the amount of knowledge and code to
determine if something is available (as a person who works in a
production environement with mixed knowledge levels of the people and
who has to analyse problems which are sometimes caused by lack of
knowledge of the people which implemented something, I welcome
everything which lowers the learning curve and complexity).
Bye,
Alexander.
--
It wasn't exactly a divorce -- I was traded.
-- Tim Conway
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
