GSoC: registration of optional kernel features via sysctl: a question to the community

[Alexander Leidinger]

Quoting Adrian Chadd <adrian at freebsd.org> (from Fri, 11 Jun 2010  
12:28:58 +0800):

> How about exposing a simple userspace API for doing this, rather than
> doing it via sysctl?
>
> That way you could "simply" tie alternative overrides in as needed for
> builds (eg, environment variables setting overrides; and/or pointing
> to a configuration file with such) but not affect any runtime
> detection the rest of the system is doing.

There is a framework (ok, one macro: FEATURE()) for the  
kern.features.X sysctl's. This exposes the features in sysctl when  
they are there. The goals of the GSoC project are to add more  
FEATURE()'s to the kernel, and to develop a way to spoof features.

A simple way of doing the spoofing part would be some bsd.XXX.mk for  
ports so that you can maybe set an env-variable to spoof features.  
This way ports can have a look at it at build-time. This is not an  
option if you want to know if a feature is there at run-time  
(spoofing-off a feature just hides the sysctl, it does not disable the  
feature or prevents the use of it, it is just an administrative way of  
telling "please respect my wish, do not use XXX", and as such we  
wheren't able to come up with an use for spoof-on).

Using an userland program -- maybe "featurectl" or "ftctl" or whatever  
-- does not hide the sysctl's, so any program which decides to use the  
sysctl's instead, will still see the administratively hidden features.

If you want to make features (sysctl) hidden in a jail (not from  
within the jail but from outside the jail), you have to do something  
in the kernel anyway, so you do not really need an additional userland  
program (it's not a problem with sysctl to do it, the question is if  
spoof-on can only cause harm or not).

So far I've seen only responses which I would describe as:
  - "rumors are there are some ports that maybe could use this"
  - "I do not have an answer for you, but maybe you could do X"

Thank you to all such answers, but as this is not some just-for-fun  
project (Google is paying money to the students for their work), I  
will tell Ilya to not care about spoof-on, if nobody is showing us a  
specific example of where spoof-on would make sense (a port where this  
makes sense would be the best way, an hypotetical example will have to  
pass a likelyness-analysis and an are-there-good-alternatives-check).  
As the GSoC is also having a deadline, I will set the deadline for  
providing such ports/examples to the end of this month.

Bye,
Alexander.

-- 
You are only young once, but you can stay immature indefinitely.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137