Date: Mon, 9 Mar 1998 07:19:20 +1100 (EST) From: John Birrell <jb@cimlogic.com.au> To: dufault@hda.com (Peter Dufault) Cc: jb@cimlogic.com.au, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/include sched.h Makefile Message-ID: <199803082019.HAA13547@cimlogic.com.au> In-Reply-To: <199803082010.PAA15845@hda.hda.com> from Peter Dufault at "Mar 8, 98 03:10:20 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Dufault wrote: > What are the options for keeping the structures in one place, > though? The data structures are already mandated to show up in that > user header and the choices are: > > 1. Don't worry about it - the kernel won't create functions that > conflict, or if they do it is because it makes sense; > > 2. Use the standard-defined header in the kernel and #ifdef out > for the kernel (as I did though I don't need to); > > 3. Create some new header file. > > I'm happy with either 1 or 2, and 2 seemed the safest for mass production. That's probably regarded as the "traditional" BSD way, so you're just being consistent. If I had my way, though, I'd design such things to make the underlying (kernel in this case) implementation opaque to the user so that changes in that don't cause recompiles of user programs. An example of what I'd prefer to avoid is the visibility that user-space has to struct proc. I like to use the concept of public and private headers. But it is "lonely" working on BSD having that opinion. 8-( -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 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?199803082019.HAA13547>