From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 9 14:54:21 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 6BBB9106570A for ; Wed, 9 Jun 2010 14:54:21 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 290CA8FC34 for ; Wed, 9 Jun 2010 14:54:20 +0000 (UTC) Received: by iwn7 with SMTP id 7so2464491iwn.13 for ; Wed, 09 Jun 2010 07:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=dCJ87RA0cOhaUCjuvtGBpYpWgavBAQ3VR0fBW7OkSfA=; b=BQ3QeKr6c4y+Bcja3lkjBXzvinxWw8pSArr6VTTrP8NXDbUUYOWT7cdTeB3iPLIuAa tU8P0ZWHWNMLriVJLlmRElDhjsa+fsQzSh/t0J/SoRJbzeS6cESgb6W8Y9SZOscR8gx6 GroV4+nqQ3Fn6A8OvLyeoeF4CWvM5TLZkTQg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ZSpmEHbznZnsBnoKliINn545urwoIkPL4KEl0fm3D135Vnez2H9RVTT3LAKR80xqy/ eDa7AHGPwrJ40n27jv9QcsJ4of01BjJar4l+UJ7jM5+tfP5FQGFhZcE1fL+GRwDVFjjI wfc6QJIt8CbaxTquDrVMikrXEdgS2fV5cfcgY= Received: by 10.231.169.9 with SMTP id w9mr1551135iby.58.1276095259964; Wed, 09 Jun 2010 07:54:19 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-128-180.dsl.klmzmi.sbcglobal.net [99.181.128.180]) by mx.google.com with ESMTPS id t28sm31265972ibg.0.2010.06.09.07.54.17 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Jun 2010 07:54:19 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C0FAB18.7010902@dataix.net> Date: Wed, 09 Jun 2010 10:54:16 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100515 Thunderbird MIME-Version: 1.0 To: Kostik Belousov References: <20100609121453.095d92b4@kibab.com> <4C0F9394.9030202@dataix.net> <20100609132543.GI83316@deviant.kiev.zoral.com.ua> In-Reply-To: <20100609132543.GI83316@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: Wed, 09 Jun 2010 14:54:21 -0000 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