Date: Thu, 10 Jun 2010 16:01:09 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: gljennjohn@googlemail.com Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-hackers@freebsd.org, Garrett Cooper <yaneurabeya@gmail.com>, Ilya Bakulin <webmaster@kibab.com> Subject: Re: GSoC: registration of optional kernel features via sysctl: a question to the community Message-ID: <20100610160109.19585782fyr3buw4@webmail.leidinger.net> In-Reply-To: <20100610101801.742fac25@ernst.jennejohn.org> References: <20100609121453.095d92b4@kibab.com> <4C0F9394.9030202@dataix.net> <20100609132543.GI83316@deviant.kiev.zoral.com.ua> <A4C894EA-8039-459B-B4C8-8F7CC98421F8@gmail.com> <20100610101801.742fac25@ernst.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Gary Jennejohn <gljennjohn@googlemail.com> (from Thu, 10 Jun
2010 10:18:01 +0200):
> On Wed, 9 Jun 2010 10:12:54 -0700
> Garrett Cooper <yaneurabeya@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100610160109.19585782fyr3buw4>