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

[Alexander Leidinger]

Quoting Gary Jennejohn <gljennjohn at googlemail.com> (from Thu, 10 Jun  
2010 10:18:01 +0200):

> 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.

That's not a surprise, currently there is nothing in kern.features to  
check for. One of the goals of the GSoC project is to add features to  
check for.

We will have something like (out of the top of my head, do not nail me  
on the spelling or a particular feature):
  kern.features.compat_4
  kern.features.compat_6
  kern.features.softupdates
  kern.features.ufs_snapshots

As soon as something is active in the kernel (directly compiled in or  
via a module), the corresponding kern.features.XXX entry will show up  
(with a value of 1). The spoofing feature which Ilya was talking about  
in this thread will for sure allow to mask an existing feature away.

The big question is: where would we need a spoofing feature where a  
non-existing feature (= no runtime support in the kernel) needs to  
show up with a value of 1 (let's call this "spoof-on")?

We identified the following obvious cases:
  - the software *needs* the feature at build-time
    -> we should not "spoof-on" a non-existing feature (build error)
  - the software needs the feature at run-time but not at
    build-time and the port/configure checks at build-time
    -> the port needs to be changed to test at run-time,
       spoof-on will hurt and is not needed (the feature is
       not used yet, so instead of changing the build to
       check for the feature systl the time is better spend
       to check at run-time -> no need for spoof-on)
  - the software needs the feature at run-time and checks
    at run-time
    -> spoof-on will hurt

What we search for is a port which does not fall into one of the above  
cases and where spoof-on does not hurt.

Bye,
Alexander.

-- 
One man's folly is another man's wife.
		-- Helen Rowland

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137