From owner-freebsd-arch Sat May 4 0:41:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id D021237B41D; Sat, 4 May 2002 00:41:33 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g447fKb5023782; Sat, 4 May 2002 03:41:20 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 4 May 2002 03:41:19 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <13810.1020419033@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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. 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