Date: Tue, 16 Jan 2001 03:50:09 +0900 (JST) From: Hajimu UMEMOTO <ume@FreeBSD.org> To: bright@wintelcom.net Cc: arch@FreeBSD.org Subject: Re: dynamic vs static sysctls? Message-ID: <20010116.035009.71081161.ume@FreeBSD.org> In-Reply-To: <20010115103757.B7240@fw.wintelcom.net> References: <20010115100618.Y7240@fw.wintelcom.net> <20010116.033215.41625863.ume@FreeBSD.org> <20010115103757.B7240@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Mon, 15 Jan 2001 10:37:57 -0800
>>>>> Alfred Perlstein <bright@wintelcom.net> said:
bright> Well all the sysctl's I've added have been dynamic, I think the
bright> only reason for the 'static' sysctls is to give sysctl() a
bright> numeric way to get at the sysctls, which isn't very useful
bright> when we have getsysctlbyname().
You mean dynamic sysctl is just use of OID_AUTO, right? I thought
SYSCTL_ADD_INT().
bright> Using a dynamic sysctl It would reduce the delta by quite a bit.
Indeed.
bright> The stuff your patch does seems to allow programs to use the old
bright> (IMHO) depricated sysctl() versus getsysctlbyname() function.
bright> No one I know wants to use sysctl instead of getsysctlbyname afaik,
bright> however, I would like to know if my opinions are the what we're
bright> aiming for.
Okey, I'll change to use OID_AUTO.
bright> Any other comments?
One question. How can I detect newly added sysctl? In static, I can
just do by #ifdef OID.
bright> Besideds the way the sysctl is done, the change is pretty nice
bright> to see, but will need mplocking later.
Do you mean ALLPROC_LOCK(AP_EXCLUSIVE) / ALLPROC_LOCK(AP_RELEASE) ?
If so, I'll move nforks++ between them.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010116.035009.71081161.ume>