Date: Thu, 7 Sep 2000 14:16:16 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Robert Watson <rwatson@FreeBSD.org>, Don Lewis <truckman@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern init_main.c kern_exec.c kern_exit.c kern_fork.c kern_proc.c kern_prot.c kern_resource.c uipc_socket.c uipc_socket2.c uipc_usrreq.c vfs_aio.c src/sys/sys proc.h resourcevar.h ucred.h Message-ID: <200009072116.OAA03992@salsa.gv.tsc.tdk.com> In-Reply-To: <Pine.NEB.3.96L.1000907170228.30548B-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1000907170228.30548B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 7, 5:04pm, Robert Watson wrote: } Subject: Re: cvs commit: src/sys/kern init_main.c kern_exec.c kern_exit.c } } > Because the pcred and ucred structures changed size, libkvm and friends } > will need to be rebuilt. } } I keep wondering to myself if we shouldn't start exporting something other } than our native in-kernel structures via sysctl--i.e., introduce a } version-controlled "exportproc" structure, and other related structs. } This would let things such as in-kernel flag changes, scheduler } modifications, etc, occur freely without breaking userland all the time. } The code in the appropriate sysctl would copy over documented, well-known } fields to exportproc. A lot of the things that change in struct proc are } of no interest to ps anyway :-). } } This becomes especially relevant when the fields of traditional single } monolithic structures (proc, cred, ...) start being broken out into more } modular structures; there's no reason for the userland sysctl api to } change as a result. We already do something like this. Take a look at struct kinfo_proc in sys/user.h. There is a sysctl hook in kern_proc.c to access this structure. The problem is that the contents are just a concatenation of proc, pcred, ucred, and a bunch of other stuff. We would need to redefine this structure to contain the stuff we want to export, and manually copy the data element by element. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009072116.OAA03992>