Date: Fri, 15 Sep 2000 12:26:56 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-arch@FreeBSD.org Subject: sysctl MIB and kernel internals Message-ID: <Pine.NEB.3.96L.1000915120346.45037J-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
As I'm sure you've frequently experienced, getting your userland and kernel out of synch can break all kinds of things, including common utilities such as ps. One reason for this is a tight coupling between the internal implementation structures in the kernel, and the exported management interface to userland. For example, sysctl(3) exposes, effectively verbatim, a direct concatenation of struct proc, the related credential and process structures, et al. This is a problem, as any trivial change to those structures, even one unrelated to the data visible to userland, will change the MIB interface breaking any compiled binaries relying on it. Also, it means exposing many kernel interneals throughout userland. For example, as part of the capalities support described in my BSDcon paper, I added a reference to struct cap in struct ucred, creating a dependency on sys/capability.h if struct ucred is to be used. The result was that the following userland source files had to be fixed with the added include: RCS file: /home/ncvs/src/contrib/amd/include/am_defs.h,v RCS file: /home/ncvs/src/include/rpcsvc/bootparam_prot.x,v RCS file: /home/ncvs/src/lib/libc/gen/getmntinfo.c,v RCS file: /home/ncvs/src/lib/libkvm/kvm_getswapinfo.c,v RCS file: /home/ncvs/src/usr.bin/find/function.c,v RCS file: /home/ncvs/src/usr.bin/kdump/Makefile,v RCS file: /home/ncvs/src/usr.sbin/inetd/builtins.c,v RCS file: /home/ncvs/src/usr.sbin/pstat/pstat.c,v RCS file: /home/ncvs/src/usr.sbin/rpc.umntall/rpc.umntall.c,v So there are several problems relating to this. 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''. 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 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?Pine.NEB.3.96L.1000915120346.45037J-100000>