From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 12 01:01:15 2011 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 BF6BC1065670; Sat, 12 Feb 2011 01:01:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 99E348FC17; Sat, 12 Feb 2011 01:01:15 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 522C446B06; Fri, 11 Feb 2011 20:01:15 -0500 (EST) Date: Sat, 12 Feb 2011 01:01:15 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ilya Bakulin In-Reply-To: <4D556C1C.6030002@kibab.com> Message-ID: References: <20110211103028.12684f54yrw8tgqo@webmail.leidinger.net> <201102110751.52863.jhb@freebsd.org> <20110211145445.12722r7902rz8vc4@webmail.leidinger.net> <4D556C1C.6030002@kibab.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Leidinger , kibab@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: CFR: FEATURE macros for AUDIT/CAM/IPC/KTR/MAC/NFS/NTP/PMC/SYSV/... 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: Sat, 12 Feb 2011 01:01:15 -0000 On Fri, 11 Feb 2011, Ilya Bakulin wrote: > When I was beginning this GSoC work, I primarily thought about unifying the > way to determine if particular feature exists in the kernel. Of course there > should be at least one way to check if the feature is available or not (by > definition: if I may use some functionality, than feature is present, > otherwise... Oh, no, may be I have no permissions to use it? or something is > terribly wrong with system confuguration? Or?...), but it is better to have > a sort of unified way to get this information without looking for files in > /dev, parsing `kldstat -v`, etc. One of the nice things about this is that when a conditionally compiled feature introduces a new system call, there can be forward (rather than backward) compatibility benefits. If login(1) had checked for the Audit feature before trying audit system calls when we introduced it in 6.x, it would have avoided a few people shooting their feet off in the (officially unsupported) case where following a kernel and userspace roll-forward, a kernel roll-back was required to restore stability. While we don't support it (you shouldn't run a new userspace with an old kernel), the failure mode would have been improved. More abstractly: for a feature like MAC, testing for the presence of the framework is functionally fairly different from exercise the feature, as most instances of exercising it work only based on modules loaded by the framework, which is a different goal. Right now, libc offers a mac_present API, which back-ends into manually testing a system call. I'd rather it backended into a common feature test framework. In many cases, it is of course desirable to test for a feature by using it -- a much more pragmatic approach, and generally one preferred in the world of autoconf, etc... Robert