Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Jan 2001 01:23:57 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        mckusick@mckusick.com (Kirk McKusick)
Cc:        bright@wintelcom.net (Alfred Perlstein), arch@FreeBSD.ORG
Subject:   Re: dynamic vs static sysctls?
Message-ID:  <200101170123.SAA19503@usr08.primenet.com>
In-Reply-To: <200101152345.PAA22257@beastie.mckusick.com> from "Kirk McKusick" at Jan 15, 2001 03:45:35 PM

next in thread | previous in thread | raw e-mail | index | archive | help
... > I want
> to do one call to sysctlnametomib (a new, but obviously trivial
> function) to return the numeric mib, and then use that mib on all
> the subsequent sysctl calls. That dramatically cuts down on the
> time it takes to return the blocks since I do not have to translate
> the same name repeatedly (which takes far longer than the block
> release itself). I would think that this might be an issue for
> any application that uses sysctl to get/set the same information
> repeatedly.

Dynamic content isn't the only thing, though.  I've used a
dynamically generated sysctl for a while to pass information
out from the kernel to user space for statistical purposes.
In general, this would be a better way of exposing things
like load average, assuming you could get the tools converted.

In my static implementation, I used a user space catalog file to
do the name/OID translation, since I didn't want to put all that
stuff in the kernel anyway.

I'm a bit concerned about the transient vs. permanent information
(a different axis from the static vs. dynamic, IMO).  The only
thing I could think of was to do what the NetWare bindery
emulation in NDS does, which is to reset the transient portion
of the data each time the system reboots, and have a "transient"
flag in the compiled database, and use the compiled database for
all my lookups (you need both indices anyway, so flat files lose
anyway).

I'm really not happy with the approach, due to Cached Data
Considered Harmful...

This smacks too much of cached data (e.g. the IP addresses of
interfaces in sendmail, which don't get updated when they are
changed out from under it via ifconfig, like they should be,
or the cached data in DNS that gets there via the protocol,
but bind doesn't notice third party config file changes, like
cron is wont to do).

But I really can't think of a nicer way that doesn't have me
shoving string data that's not a filesystem path across the
user/kernel boundary, in both directions.  8-(.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


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?200101170123.SAA19503>