From owner-freebsd-current Mon Feb 12 18:50:33 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3DA5837B4EC; Mon, 12 Feb 2001 18:50:19 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id NAA18520; Tue, 13 Feb 2001 13:50:15 +1100 Date: Tue, 13 Feb 2001 13:49:50 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Robert Watson Cc: Dag-Erling Smorgrav , Jake Burkholder , 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 ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Feb 2001, Robert Watson wrote: > On 12 Feb 2001, Dag-Erling Smorgrav wrote: > > > Jake Burkholder 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