Date: Sun, 8 Mar 1998 16:44:40 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: jb@cimlogic.com.au (John Birrell) Cc: cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/include sched.h Makefile Message-ID: <199803082144.QAA16102@hda.hda.com> In-Reply-To: <199803082019.HAA13547@cimlogic.com.au> from John Birrell at "Mar 9, 98 07:19:20 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> 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-( Don't feel lonely - the kernel implementation can remain opaque. Sharing the header is intended to allow standard C sharing (avoiding details about structure setup etc.) of some as of yet unused piece of the structure between the kernel and the user space, for eample, to avoid lookup style operations in the kernel with a cookie. The user space can't do much with an opaque kernel cookie but it may help the kernel. The intent of ifdef KERNEL is to hide ISO standardized POSIX function interfaces from the kernel to avoid conflicts - protection against a stupid thing that you haven't accused me of but which is my critique of putting it there. My kernel interfaces are kept in posix4/posix4.h. I'm happy to agree that the kernel shouldn't have such interfaces, or that when present they must be consistent with the spec. I'll rip out ifdef KERNEL. About posix4 - we all agree it is a dumb name. Let's leave it and the associated implementation macros that way for a while and agree we'll change it later - I'll finish up setting it up so you can set _POSIX_VERSION to 199309L and lkm in the pieces I have while I order the latest spec and look it over. Anyone else who has to work with that right now won't care either. Then we can move that subdirectory to a more sensible place. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval 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?199803082144.QAA16102>