Date: Fri, 11 Jun 2010 11:08:27 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Adrian Chadd <adrian@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-hackers@freebsd.org, Garrett Cooper <yaneurabeya@gmail.com>, Ilya Bakulin <webmaster@kibab.com> Subject: Re: GSoC: registration of optional kernel features via sysctl: a question to the community Message-ID: <20100611110827.94483dvv07ske0ao@webmail.leidinger.net> In-Reply-To: <AANLkTimTVmKz2b50GWTDktRTqJaKMsxOz4Uuo6wJP2Rj@mail.gmail.com> References: <20100609121453.095d92b4@kibab.com> <4C0F9394.9030202@dataix.net> <20100609132543.GI83316@deviant.kiev.zoral.com.ua> <A4C894EA-8039-459B-B4C8-8F7CC98421F8@gmail.com> <20100610101801.742fac25@ernst.jennejohn.org> <20100610160109.19585782fyr3buw4@webmail.leidinger.net> <AANLkTimTVmKz2b50GWTDktRTqJaKMsxOz4Uuo6wJP2Rj@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Adrian Chadd <adrian@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100611110827.94483dvv07ske0ao>