From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 3 11:05:52 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 F0D7F194 for ; Mon, 3 Nov 2014 11:05:52 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A88C0E59 for ; Mon, 3 Nov 2014 11:05:52 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA3B5jsk022914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 3 Nov 2014 03:05:49 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54576181.5010405@freebsd.org> Date: Mon, 03 Nov 2014 19:05:37 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov , Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org Subject: Re: [maybe spam] Re: [PATCH] Finish the task 'sysctl reporting current working directory' 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> <20141103104052.GL53947@kib.kiev.ua> In-Reply-To: <20141103104052.GL53947@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 11:05:53 -0000 On 11/3/14, 6:40 PM, Konstantin Belousov wrote: > 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. I withdraw my comment.. :-) > >