Date: Wed, 09 Jun 2010 10:54:16 -0400 From: jhell <jhell@dataix.net> To: Kostik Belousov <kostikbel@gmail.com> Cc: Ilya Bakulin <webmaster@kibab.com>, freebsd-hackers@freebsd.org Subject: Re: GSoC: registration of optional kernel features via sysctl: a question to the community Message-ID: <4C0FAB18.7010902@dataix.net> 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 06/09/2010 09:25, 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.
That would lead me to believe that the elimination of this sysctl would
be better suited to solve the outcome of cases like this.
And leads me to believe that it still rests on the end-user to tell
whether or not they have that compatibility layer compiled in.
Like I stated more towards the end of my last message "I believe"
checking __FreeBSD_version should suffice and leave the final result up
to the end-user as GENERIC will have the COMPAT_FREEBSD{N} layers
compiled in that it needs or can support or are recommended.
Being that this is a broad scenario and many different compilations of
kernels could be used I still do not see a need to test for every one of
them if an adequate means already exists. GENERIC in any case should be
the kernel that is depended on and testing against __FreeBSD_version for
what COMPAT versions are supported.
Regards,
--
jhell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C0FAB18.7010902>