From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 10:40:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C527D7C0; Mon, 3 Nov 2014 10:40:57 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6742BC3E; Mon, 3 Nov 2014 10:40:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sA3AeqdO019187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2014 12:40:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sA3AeqdO019187 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sA3Aeqn7019185; Mon, 3 Nov 2014 12:40:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 3 Nov 2014 12:40:52 +0200 From: Konstantin Belousov To: Mateusz Guzik , Julian Elischer , Tiwei Bie , freebsd-hackers@freebsd.org Subject: Re: [PATCH] Finish the task 'sysctl reporting current working directory' Message-ID: <20141103104052.GL53947@kib.kiev.ua> References: <1414987325-23280-1-git-send-email-btw@mail.ustc.edu.cn> <20141103051908.GC29497@dft-labs.eu> <20141103064052.GA1739@freebsd> <5457394E.4050905@freebsd.org> <20141103084129.GF29497@dft-labs.eu> <20141103090940.GI53947@kib.kiev.ua> <20141103102005.GI29497@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141103102005.GI29497@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 10:40:58 -0000 On Mon, Nov 03, 2014 at 11:20:05AM +0100, Mateusz Guzik wrote: > On Mon, Nov 03, 2014 at 11:09:40AM +0200, Konstantin Belousov wrote: > > On Mon, Nov 03, 2014 at 09:41:29AM +0100, Mateusz Guzik wrote: > > > On Mon, Nov 03, 2014 at 04:14:06PM +0800, Julian Elischer wrote: > > > > why are you using a fixed sysctl MIB number? > > > > I thought we were moving towards dynamic sysctls when we add new ones. > > > > > > > > > > We are? KERN_PROC_* seems to be a complete list with SIGTRAMP added last > > > year. > > > > > > I guess we can do it with OID_AUTO, if there will be any need we can > > > switch it back to a static var. > > > > I am very curious how would you make kern.proc.cwd auto, while > > still using kern.proc leaf. And more important question is, why ? > > Unclear what you mean. I just tested with marking it OID_AUTO and it > works. Typical caller of other sysctls from kern.proc family does (slightly edited code from libunwind): int mib[4], error, ret; size_t len, len1; len = 0; mib[0] = CTL_KERN; mib[1] = KERN_PROC; mib[2] = KERN_PROC_VMMAP; mib[3] = pid; > > Userspace code does sysctlbyname to look it up and sysctl + mib[3] = pid to > call, no problems that I can see. Yes, but currently userspace does not need to do this dance (for other kern.proc sysctls). > > I'm not a fan of this because of the need for lookup for what is a > compiled in and always available sysctl. > > I only said we can do OID_AUTO because of Julian's complaint. Was about > to do some search for apparent agreement to not add more static sysctls, > but your reply suggests there was no such thing. It is reasonable to not manage allocation of oids for things which are hard or impossible to statically manage, e.g. the leafs from dynamically loaded modules, or leafs describing the device tree on the machine, where structure of the tree depends on the local conditions. Trying to enforce this rule for oids where only static tree is used only complicates life for consumers without any benefits for code clarity or extensibility. > > That said, I prefer static version. Agree.