From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 9 17:37:33 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 4DE89106566B for ; Wed, 9 Jun 2010 17:37:33 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D1C958FC0C for ; Wed, 9 Jun 2010 17:37:32 +0000 (UTC) Received: by wyb33 with SMTP id 33so958418wyb.13 for ; Wed, 09 Jun 2010 10:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=iOnKka2rObKP5WTyURMnNAEgJJ+OcnxbUO8fS5KnevM=; b=GWNCkwtX1wha1oq/zpqOsvT1K65eRGCxPVOGcvgjC1lxvoQU4rud2mRZqJu5/oa3vI Q0erTyKq2JlXgGwTTjOUYk7szNZkG/Lkz2wCbjSv8hjMOa6L5otMyaihHtuCZesSczoU yuWj2YfftV/k9VM/X/B6MERnWnrCj/k/H5eD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=tuawCngHD0vEhfvKrqQKxU2Fsdyp+RNP0NaXkVsV03Dcb2tI6IBqPKVPx/byYR7IyK PLN8l3ZmI4N52fN9PhqbPwxm2zqOSmupsGk6TRcCWZXaYuBfVIBDZPdA98pjfduewni2 o8ZriK/XMS/U9Wprm16gfxr7AidRJ9AiQemdc= Received: by 10.227.155.204 with SMTP id t12mr5277276wbw.29.1276103580101; Wed, 09 Jun 2010 10:13:00 -0700 (PDT) Received: from [192.168.0.204] (deviant.freebsdgirl.com [173.8.183.73]) by mx.google.com with ESMTPS id b14sm2687418wbb.5.2010.06.09.10.12.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Jun 2010 10:12:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20100609132543.GI83316@deviant.kiev.zoral.com.ua> Date: Wed, 9 Jun 2010 10:12:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100609121453.095d92b4@kibab.com> <4C0F9394.9030202@dataix.net> <20100609132543.GI83316@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Wed, 09 Jun 2010 17:47:29 +0000 Cc: freebsd-hackers@freebsd.org, 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: Wed, 09 Jun 2010 17:37:33 -0000 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! >>>=20 >>> 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=20= >>> 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? >>>=20 >>=20 >> 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. Would be nice if the overrides could be built into ports with sensible = defaults and everything would default to a value instead of being = hardwired to strictly detect said functionality... but that's what = ultimately requires work to fix. -Garrett=