CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/...

[Alexander Leidinger]

Quoting John Baldwin <jhb at 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