From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 10 14:01:14 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 DE88F1065673 for ; Thu, 10 Jun 2010 14:01:13 +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 85B208FC19 for ; Thu, 10 Jun 2010 14:01:13 +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 005A284400A; Thu, 10 Jun 2010 16:01:09 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 492C7512E; Thu, 10 Jun 2010 16:01:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1276178466; bh=+i+ubqlLfB/2gxl1goNnFQdhpexWMaDz7gbi7SM8gsk=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=p8Ogb8QYokXYgbeRWRfQM5gqskiLG9vp1xfQy1K8fwZWXFCPNuZ/UDqe8Gdln5J0O FtszqKVTywMBeyjBXwfeVbFXmQr/H/05rzgubw9i+oUa3zT41A+l1vaGdjTNj9KfH0 kwbprLpPR04/nYw3XyFAayjbb4M87WRedaboC8jRQUtE0nHdxkJIPPit+fei8B+fNs 42Oal4s91ZuhrQaMGTG5vL5J30uvVOues7BPW8837Nvjw+YLflDxRScuPrWYFkAlb3 3TIfPgCyjkZ3NvU9wgpeUzsRUO5Gifja8jGdrkTwNtCsGukuKPy0lSo5/zhbNnsWeG pJ1He355OKMIQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o5AE15IY035992; Thu, 10 Jun 2010 16:01:05 +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:04 +0200 Message-ID: <20100610160104.16285uq2jhuio34s@webmail.leidinger.net> Date: Thu, 10 Jun 2010 16:01:04 +0200 From: Alexander Leidinger To: jhell References: <20100609121453.095d92b4@kibab.com> <4C0F9394.9030202@dataix.net> <20100609132543.GI83316@deviant.kiev.zoral.com.ua> <4C0FAB18.7010902@dataix.net> In-Reply-To: <4C0FAB18.7010902@dataix.net> 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: 005A284400A.A8B86 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1276783270.91309@JbfyCxaJuohDnSCKz4293Q X-EBL-Spam-Status: No X-Mailman-Approved-At: Thu, 10 Jun 2010 14:10:58 +0000 Cc: Kostik Belousov , Ilya Bakulin , freebsd-hackers@freebsd.org 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:14 -0000 Quoting jhell (from Wed, 09 Jun 2010 10:54:16 -0400): > 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. Maybe there is a misconception of what is being done. 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. __FreeBSD_version is not adequate at all for things which require a feature to be present in the kernel (can be removed in a custom kernel) and are required at run-time (build-time checks do not help here, just think about building and installing a program, and then changing the kernel config and installing a new kernel). Bye, Alexander. -- "Don't worry. Clemenza is OK. It's Paulie." -- Santino Corleone, "Chapter 4", page 93 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137