From owner-freebsd-arch Fri Sep 15 17:40:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 1A15137B423; Fri, 15 Sep 2000 17:40:31 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.0/8.11.0) with ESMTP id e8G0b3v29208; Sat, 16 Sep 2000 01:37:03 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.0/8.11.0) with ESMTP id e8G0b2n00679; Sat, 16 Sep 2000 01:37:02 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200009160037.e8G0b2n00679@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Robert Watson Cc: freebsd-arch@FreeBSD.org, brian@Awfulhak.org Subject: Re: sysctl MIB and kernel internals In-Reply-To: Message from Robert Watson of "Fri, 15 Sep 2000 12:26:56 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Sep 2000 01:37:02 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 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