From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 11 13:54:54 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 793D91065670; Fri, 11 Feb 2011 13:54:54 +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 60CDE8FC1B; Fri, 11 Feb 2011 13:54:52 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B9CC.dip.t-dialin.net [87.179.185.204]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 2A523844012; Fri, 11 Feb 2011 14:54:49 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id E4CAA2F64; Fri, 11 Feb 2011 14:54:45 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p1BDsjWr032115; Fri, 11 Feb 2011 14:54:45 +0100 (CET) (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; Fri, 11 Feb 2011 14:54:45 +0100 Message-ID: <20110211145445.12722r7902rz8vc4@webmail.leidinger.net> Date: Fri, 11 Feb 2011 14:54:45 +0100 From: Alexander Leidinger To: John Baldwin References: <20110211103028.12684f54yrw8tgqo@webmail.leidinger.net> <201102110751.52863.jhb@freebsd.org> In-Reply-To: <201102110751.52863.jhb@freebsd.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: 2A523844012.A7430 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.274, required 6, autolearn=disabled, RDNS_NONE 1.27) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1298037289.71466@LQBnulvZjSdFiOavtlmv+Q X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 11 Feb 2011 14:48:48 +0000 Cc: freebsd-hackers@freebsd.org, kibab@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: Fri, 11 Feb 2011 13:54:54 -0000 Quoting John Baldwin (from Fri, 11 Feb 2011 07:51:52 -0500): > On Friday, February 11, 2011 4:30:28 am Alexander Leidinger wrote: >> Hi, >> >> during the last GSoC various FEATURE macros where added to the system. >> Before committing them, I would like to get some review (like if macro >> is in the correct file, and for those FEATURES where the description >> was not taken from NOTES if the description is OK). >> >> If nobody complains, I would like to commit this in 1-2 weeks. If you >> need more time to review, just tell me. >> >> Here is the list of affected files (for those impatient ones which do >> not want to look at the attached patch before noticing that they are >> not interested to look at it): > > Hmm, so what is the rationale for adding FEATURE() macros? Do we > just want to > add them for everything or do we want to add them on-demand as use cases for > each knob arrive? Some features can already be inferred (e.g. if KTR is The non-answer is: IMO we want to add as much as needed. See below for an explanation. > compiled in, then the debug.ktr.mask sysctl will exist). Also, in > the case of > KTR, I'm not sure that any userland programs need to alter their behavior > based on whether or not that feature was present. The main goal was to have an easy way (e.g. not a lot of parsing) without sideeffects (e.g. autoloading of kernel modules) to query if a feature is available. Regarding this, there is no need to have one for KTR. The 2nd goal is (as you know, as we discussed it in the beginning of the GSoC) to be able to hide a feature administratively (I plan to commit the userland part regarding this last). You can not do this with sysctl, so for me adding a FEATURE for KTR provides more possibilities. I see a use case for this in KTR, an app may see if it is there and start some tracing based upon it (and it could be adminsitratively prohibited by hiding the presence), or there could be a sanity check in a script which prevents some tracing-setup to happen if it is not there (or administratively hidden). In general I do not want to decide if something makes sense for an app or not, as I do not think I can come up with all possible use cases (possibilities instead of policies). As such it makes sense to add more FEATURE macros to the tree than what we have ATM. If used correctly (via the to be committed userland part), this may make the life of some people more easy. As a 3rd point (attention bikeshed ahead), having everything as a FEATURE would give an uniform way of listing what is available or not (with the benefit to administratively hide parts of it). Needless to say that this would reduce the amount of knowledge and code to determine if something is available (as a person who works in a production environement with mixed knowledge levels of the people and who has to analyse problems which are sometimes caused by lack of knowledge of the people which implemented something, I welcome everything which lowers the learning curve and complexity). Bye, Alexander. -- It wasn't exactly a divorce -- I was traded. -- Tim Conway http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137