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

[Robert Watson]

On Fri, 11 Feb 2011, Ilya Bakulin wrote:

> When I was beginning this GSoC work, I primarily thought about unifying the 
> way to determine if particular feature exists in the kernel. Of course there 
> should be at least one way to check if the feature is available or not (by 
> definition: if I may use some functionality, than feature is present, 
> otherwise... Oh, no, may be I have no permissions to use it? or something is 
> terribly wrong with system confuguration? Or?...), but it is better to have 
> a sort of unified way to get this information without looking for files in 
> /dev, parsing `kldstat -v`, etc.

One of the nice things about this is that when a conditionally compiled 
feature introduces a new system call, there can be forward (rather than 
backward) compatibility benefits.  If login(1) had checked for the Audit 
feature before trying audit system calls when we introduced it in 6.x, it 
would have avoided a few people shooting their feet off in the (officially 
unsupported) case where following a kernel and userspace roll-forward, a 
kernel roll-back was required to restore stability.  While we don't support it 
(you shouldn't run a new userspace with an old kernel), the failure mode would 
have been improved.

More abstractly: for a feature like MAC, testing for the presence of the 
framework is functionally fairly different from exercise the feature, as most 
instances of exercising it work only based on modules loaded by the framework, 
which is a different goal.  Right now, libc offers a mac_present API, which 
back-ends into manually testing a system call.  I'd rather it backended into a 
common feature test framework.

In many cases, it is of course desirable to test for a feature by using it -- 
a much more pragmatic approach, and generally one preferred in the world of 
autoconf, etc...

Robert