Date: Sat, 16 Sep 2000 01:37:02 +0100 From: Brian Somers <brian@Awfulhak.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org, brian@Awfulhak.org Subject: Re: sysctl MIB and kernel internals Message-ID: <200009160037.e8G0b2n00679@hak.lan.Awfulhak.org> In-Reply-To: Message from Robert Watson <rwatson@FreeBSD.org> of "Fri, 15 Sep 2000 12:26:56 EDT." <Pine.NEB.3.96L.1000915120346.45037J-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'd like to see us consider moving to an alternative model, divorcing the
> implementation internals of various kernel objects (processes, et al) from
> the MIB interface retrieving management data about them. I.e., struct
> proc would continue to be used in kernel, but relevant fields would be
> copied to struct export_proc for export via sysctl. In addition, it would
> be worth prefixing these exported structures with a version number
> allowing the caller to determine if they support an appropriate version of
> the interface, allowing a more comprehensible error. Only fields
> desirable to export would be in export_proc, so if an extra pointer is
> added to struct ucred (recent resource control changes, capabilities), an
> extra pointer to struct proc (jail), etc won't needless break userland
> tools.
>
> This would also have the effect of allowing us to document the MIB, rather
> than just say, ``err. go see the kernel source''.
One other thing worth adding - a length if it's not there:
struct something_exported {
int version;
size_t len;
field1;
field2;
...
};
This way, extra user-land fields can be added to the end with len
increased but version not increased.
FWIW Solaris has taken this one step further with their kstat stuff.
A driver can add and remove statistics of different types to the kstat
tree on-the-fly. The types can be lists of named variables, for example
module.instance.name.variable = value
that can be read (or written) generically, or ``raw data'' (still having
a module, instance and name) with a size and repetition count - treated
as a known structure by the kernel & app. There are other types, but I
can't remember what they are.... The nice thing about the structured
data is that it's easy to add more stuff without breaking user-land.
I don't think it's *that* useful though (not useful enough to suggest
we add anything to our MIB interface), but worth knowing.
> Just a thought.
>
> Robert N M Watson
>
> robert@fledge.watson.org http://www.watson.org/~robert/
> PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
> TIS Labs at Network Associates, Safeport Network Services
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
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?200009160037.e8G0b2n00679>