Date: Tue, 07 May 2002 17:37:16 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: John Baldwin <jhb@FreeBSD.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, arch@FreeBSD.org Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <89017.1020785836@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 07 May 2002 10:33:20 EDT." <XFMail.20020507103320.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, seems like some sort of concensus is building. Now for a bit of radical thinking. The FreeBSD kernel is already a multi-API kernel, we have freebsd syscalls, including various old compat stuff, we have NetBSD compat, we have BSDI compat, Linuxolator, IBCS2, and we will probably have Solaris compat on the sparc64 platform. We cannot easily compile for two native APIs if we cannot have two different set of 'sys/*' and 'machine/*' files since a lot of the types we want to change size on are defined in these files. I would therefore like to propose that we do something like the following: Repocopy src/sys/sys/* to src/sys/include Repocopy src/sys/sys/* to src/sys/abi4 Remove src/sys/sys/* In src/sys/include we remove everything which deals with syscall parameters, but retain kernel internal data structures. Stuff like vnodes, and similar lives here. In src/sys/abi4 we remove everything that we leave behind in src/sys/include. (A similar split should be done for src/sys/$arch/include into a src/sys/$arch/abi4 directory) In .c land we repocopy the relevant sys/kern/*.c files into sys/abi4 and remove everything but the syscall entry points and add explicit conversions to arguments as needed. We now have a clean split between the stuff which defines what goes on in the kernel and the stuff which defines the ABI to userland. Adding a new ABI is now a matter of creating the relevant directories (src/sys/abi5) and populating with files which does it right. I see many advantages to this way of doing things: We can remove practically all "#ifdef _KERNEL" from the .h files we install in /usr/include/sys and we can get a fair bit closer to whatever the standard-du-jour dictates that we put there. Conversely we can clean the kernel side of things (src/sys/include) for things we don't want people to use in the kernel, but which standards or compatibility demand we put in <sys/blah.h>. We also get a clear kernel / userland split on C types, we may find it convenient to operate on a 64 bit foo_t in the kernel but leave it 32 bit in userland and this lets us trivially do so. This should put a good bit of infrastructure in to make current and future API/ABI implementations simpler and more structured. I guess a way to sum this up is that it will put all API/ABI's on equal footing. With this change none of them will be any more "native" than any other API/ABI. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89017.1020785836>