Date: Fri, 6 Jul 2001 01:06:00 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: Warner Losh <imp@harmony.village.org>, current@FreeBSD.ORG Subject: Re: kernel getting files from out of kernel tree. Message-ID: <Pine.BSF.4.21.0107060029001.56947-100000@besplex.bde.org> In-Reply-To: <3B441FFC.8292F1F9@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Jul 2001, Julian Elischer wrote: > ok I understand you now, and what I'm saying is that we should > do a little work on avoiding this. We've already done a little. Of course, The problem is larger than when we started. > Most of the external includes are simply doing so to get to some > value that is defined in the kernel anyhow when the external include > then includes a kernel include file. > take for example db_command.c > > it includes <setjmp.h> which gets satisfied by the line you show below.. > but it is only calling that for the prototype of setjmp. > > If you put the prototype in a file /sys/sys/setjmp.h > then it works. (along with an include of "machine/setjmp.h") > alternatively adding it to systm.h works for me.. > > Actually the fact that userland and kernel setjmps are identical > is something that I don't think we should be depending on.... > The kernel SHOULD have it's own definition somewhere, in which case > db_command.c could just include machine/setjmp.h without needing the > user one.... setjmp.h is a bad example, because: - the userland part only declares the interface for the functions, and it won't change (if the kernel wanted functions with a different interface, then it shouldn't name them setjmp(), etc.). Some of the work already done was to move the MD parts of setjmp.h to <machine/setjmp.h>. - the kernel shouldn't use setjmp() anyway. It was only used in ddb > Another example: changing quad.h in the kernel > to include > <sys/syslimits.h> > and > <machine/limit.h> > > instead of > <limit.h> > > removes the dependency of all the quad instructions on user space. Better example. Similarly for all the includes of <string.h> in libkern. However, many things in libkern are supposed to be copies of userland files. The are very unlikely to become incompatible with the userland headers, and if you change them they will be further from being copies than before. > I include a diff that removes a whole bunch of /usr/include inclusions in the > kernel. > > I'm sure BDE could remove many more in a few minutes. (or make these cleaner) Not easily. Most of the others are the hardest to remove. They are <link.h> and related headers (for the kernel linker), and billions of rpc headers (for netatm). 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.0107060029001.56947-100000>