Date: Wed, 9 Jun 2010 10:12:54 -0700 From: Garrett Cooper <yaneurabeya@gmail.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Ilya Bakulin <webmaster@kibab.com> Subject: Re: GSoC: registration of optional kernel features via sysctl: a question to the community Message-ID: <A4C894EA-8039-459B-B4C8-8F7CC98421F8@gmail.com> In-Reply-To: <20100609132543.GI83316@deviant.kiev.zoral.com.ua> References: <20100609121453.095d92b4@kibab.com> <4C0F9394.9030202@dataix.net> <20100609132543.GI83316@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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! >>>=20 >>> 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=20= >>> 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? >>>=20 >>=20 >> 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. Would be nice if the overrides could be built into ports with sensible = defaults and everything would default to a value instead of being = hardwired to strictly detect said functionality... but that's what = ultimately requires work to fix. -Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A4C894EA-8039-459B-B4C8-8F7CC98421F8>