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

Garrett Cooper yaneurabeya at gmail.com
Wed Jun 9 17:37:33 UTC 2010


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.

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


More information about the freebsd-hackers mailing list