Date: Tue, 13 Feb 2001 13:49:50 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Dag-Erling Smorgrav <des@ofug.org>, Jake Burkholder <jburkholder0829@home.com>, freebsd-current@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ... Message-ID: <Pine.BSF.4.21.0102131336390.10359-100000@besplex.bde.org> In-Reply-To: <Pine.NEB.3.96L.1010212093948.87908B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Feb 2001, Robert Watson wrote: > On 12 Feb 2001, Dag-Erling Smorgrav wrote: > > > Jake Burkholder <jburkholder0829@home.com> writes: > > > As I mentioned in the commit message, this changes the size and layout > > > of struct kinfo_proc, so you'll have to recompile libkvm-using programs. > > > > I thought the whole point with kinfo_proc was to avoid this kind of > > situation... > > It seems to me that kinfo_proc is the wrong solution to a real problem. > > John Baldwin and I briefly discussed, online, an alternative solution that > breaks out the per-process information into a series of sysctl's. This But sysctls are the wrong solution for all problems :-). > using base types for the fields, such as int). kinfo_proc addresses the > issue that the kernel and userland concepts of a proc diverge due to the > introduction of kernel-only fields, but doesn't really address issues such > as ordered elements of the structure changing size. These issues shouldn't cause problems. You just preserve the order and don't use any kernel structs. Using application interface structs like struct rusage and struct rtprio is safe enough since if they change then you have worse problems with the binary compaitibility of the syscalls that use them. The errors in the recent commit were: (1) using the kernel struct `struct priority' (2) not preserving the old priority fields. Point (1) wouldn't have caused breakage immediately if the priority fields had been copied to their old places. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0102131336390.10359-100000>