Date: Sat, 4 May 2002 03:41:19 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Poul-Henning Kamp <phk@freebsd.org> Cc: arch@freebsd.org Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <Pine.NEB.3.96L.1020504032841.21461e-100000@fledge.watson.org> In-Reply-To: <13810.1020419033@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 May 2002, Poul-Henning Kamp wrote:
> Questions:
>
> 1. Are there anything else that needs to change size while we're
> at it ?
Well, you had the SysVIPC stuff in there anyway, so if you're going to
break the ABI, could you modify it so the uid and gid fields use uid_t and
gid_t, and if we don't use mode_t for the perm field already (I think we
do), start using mode_t there also?
I have patches that break out the user and kernel structures for sysvipc,
but they are pretty dated. I needed these to add MAC support for them,
and to start locking them down for SMPng, since both MAC labels and lock
entries shouldn't go in the user/kernel interface structure, which in
theory is a fixed and well-defined structure.
> 2. Is this a good occation to create a new syscall vector for
> FreeBSD 5.0 rather than embellish the existing one with even
> more variations ?
John Baldwin and I have thrown this idea around a number of times, as we
keep bumping into things that would change the ABI. Doing this doesn't
save you from having to write the compatibility code, but it would sure
make the syscalls.master file cleaner as we go forwards, and help a lot
with the binary compatibility issue. Here's my opinion: if it's a change
that can be made by one person in one week without boatloads of lasting
compatibility and ABI concerns, and you're volunteering to do it, then I
think it's a great idea. However, there are some technical questions to
answer, including how we identify binaries using the new ABI, etc. If
we're going to generate a new syscall table, 5.0 is definitely the time to
do it, however, so I think it's now or 6.0. And we should make sure we
really catch everything while we're here. I agree with Bruce's concerns
about the possible impact on a release date, hence specifying "a week" as
the implementation time frame.
<here ends material contribution to the discussion of whether we should go
with what you've proposed, what follows is more on the speculation side>
Another idea I've been bumping around for a bit is to better divorce the
"system call" and "service" implementations in the kernel. I don't
remember if I ever sent the picture out to -arch before, but it goes
something like this:
Now:
+------------------------------+ +-----------+ +---------------+
| FreeBSD ABI + basic service | | Linux ABI | | Foo ABI ..... |
| implementation | +-----------+ +---------------+
| | || ||
| +---------------------------------+
| |
+----------------------------------------------------------------+
||
... VFS, Scheduler, VM, ...
Possible future layout:
+-----------------+ +---------------+ +-----------+ +-------------+
| FreeBSD Old ABI | | FreeBSD 5 ABI | | Linux ABI | | Foo ABI ... |
+-----------------+ +---------------+ +-----------+ +-------------+
|| || || ||
+------------------------------------------------------------------+
| Basic service implementation |
+------------------------------------------------------------------+
||
... VFS, Scheduler, VM, ...
The goal of such a picture would be that, in general, the ABI layers would
have the sole purpose of bringing in arguments, mapping native ABI
structures to internal service structures, construction uio's, etc. Then
the service implementation would largely deal with kernel-derived
arguments, or ones where a specific user vs. kernel flag would be present
to indicate the source of the arguments. This would facilitate writing
kernel code that invokes kernel APIs, such as mount, etc, by avoiding
situations where use of user addresses is hard-coded into kernel APIs. In
many cases, it actually wouldn't mean much in the way of changes, and the
lines might not always be clean (especially when a service implementation
was specific to an ABI because it wasn't widely required). If we moved to
a FreeBSD 5 ABI, now would be a good time to do that -- we'd make the
FreeBSD 5 structures be the "native" ones used for the service
implementations, then map past FreeBSD structures into them in the FreeBSD
Old ABI. We already have this sort of layout in many places in the VFS
code, to be honest.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
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?Pine.NEB.3.96L.1020504032841.21461e-100000>