From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 10 14:01:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BE841065676 for ; Thu, 10 Jun 2010 14:01:18 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id C3CAC8FC08 for ; Thu, 10 Jun 2010 14:01:17 +0000 (UTC) Received: from outgoing.leidinger.net (pD954FE15.dip.t-dialin.net [217.84.254.21]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E5C3A84405D; Thu, 10 Jun 2010 16:01:12 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id F23EF512F; Thu, 10 Jun 2010 16:01:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1276178470; bh=HcPrudxpxLqS+U0NedjPixqJKzBYsz/XKYvgqn5aND0=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=sLvxMRZV/YQB8F7+lVk2pC61pB2KqSQ0iQXEROb02fEmnW9Yox1CodzjBdTl6/uDt ePcfGgqUT0zlQ7nMJ8djkgUfmFS0RGCibDxrAEVI3T268xFwrVYu4R/ApVb/8mycS0 5NxmAmlyXXhjH+R0Y0en26BJWLtL8zgYp8+ELy3mLTnephpT9fYRuw0dvt3FRIADZR R3J2m5IAvO+bJkSBPtBbtn+G+fycigiQDyQzAEEHenHtmtATH+ofs6+Ty1oFEW92RS +gVlW0gc5UWDJhwb+bHdp6efPYT43lTr52GC2Cq1vMD8v/ck427KJOfaOobTy2x5cA t0y1t0fTB2u0A== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o5AE19n8036646; Thu, 10 Jun 2010 16:01:09 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 10 Jun 2010 16:01:09 +0200 Message-ID: <20100610160109.19585782fyr3buw4@webmail.leidinger.net> Date: Thu, 10 Jun 2010 16:01:09 +0200 From: Alexander Leidinger To: gljennjohn@googlemail.com References: <20100609121453.095d92b4@kibab.com> <4C0F9394.9030202@dataix.net> <20100609132543.GI83316@deviant.kiev.zoral.com.ua> <20100610101801.742fac25@ernst.jennejohn.org> In-Reply-To: <20100610101801.742fac25@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: E5C3A84405D.A82A7 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.5, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BR_SPAMMER_URI 2.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_48 0.60) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1276783275.65343@5yqbKXSQyv3MiHqpVh3vCw X-EBL-Spam-Status: No X-Mailman-Approved-At: Thu, 10 Jun 2010 15:49:03 +0000 Cc: Kostik Belousov , freebsd-hackers@freebsd.org, Garrett Cooper , Ilya Bakulin Subject: Re: GSoC: registration of optional kernel features via sysctl: a question to the community X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:01:18 -0000 Quoting Gary Jennejohn (from Thu, 10 Jun 2010 10:18:01 +0200): > On Wed, 9 Jun 2010 10:12:54 -0700 > Garrett Cooper 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