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

[Gary Jennejohn]

On Wed, 9 Jun 2010 10:12:54 -0700
Garrett Cooper <yaneurabeya at gmail.com> wrote:

> On Jun 9, 2010, at 6:25 AM, Kostik Belousov wrote:
> 
> > On Wed, Jun 09, 2010 at 09:13:56AM -0400, jhell wrote:
> >> On 06/09/2010 04:14, Ilya Bakulin wrote:
> >>> Hi hackers!
> >>> 
> >>> While discussing my project's implementation details with my mentor,
> >>> Alexander Leidinger, we've found that one of the ideas needs to be discussed with community,
> >>> to find out possible use cases.
> >>> That is, if it should be possible to spoof non-existing features. For
> >>> example, if currently running kernel doesn't support FreeBSD 5.0 compat
> >>> layer, "kern.features.compat_freebsd5" will be absent when querying 
> >>> features list. The question is -- are there any cases when we want
> >>> "kern.features.compat_freebsd5" be present? If some feature is not in
> >>> kernel, then presenting its existence to the userland is useless
> >>> and may be even harmful, if, for example, some application relies on this feature.
> >>> Or there are some scenarios where such cheat is useful?
> >>> 
> >> 
> >> I can not think of any viable reason why one would want to "spoof" this
> >> when it is not available.
> > Many ports are doing wrong thing there, checking for run-time features at
> > the build-time, turning on/off some functionality depending on its
> > presence on the build host.
> 
> It's present in the ports Makefiles as well as in many autoconf scripts. It's bad because it causes problems with cross-build and other related scenarios, where you can't assume that the host system is going to match the target system.
> 

I don't find one single file in the ports tree which uses kern.features.

But I just checked what's in the tree, not what may be in the ports themselves, i.e.,
I didn't extract/configure any ports.

--
Gary Jennejohn