Date: Tue, 7 May 2002 07:36:44 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Terry Lambert <tlambert2@mindspring.com> Cc: Garance A Drosihn <drosih@rpi.edu>, Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <Pine.NEB.3.96L.1020507073404.70660A-100000@fledge.watson.org> In-Reply-To: <3CD73A71.BF0AF3A@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 May 2002, Terry Lambert wrote: > Garance A Drosihn wrote: > > At 3:41 AM -0400 5/4/02, Robert Watson wrote: > > >John Baldwin and I have thrown this idea around a number > > >of times, as we keep bumping into things that would change > > >the ABI. > > > > What things would those be? Might as well get them listed, > > and see how many of them (if any...) could be included in > > this new vector without hurting the timetable. > > Apart from the obvious "stat" values and time_t, there's also nlink_t, > dev_t, etc.... and if we're really clever, a version number for the stat > structure, as the first element. I have a few in my queue that don't relate to UFS2, and that includes updating the ipcperm structure to use uid_t and gid_t rather than u_short. This breaks the ABI for most of the sysv calls, if not all of them, unfortunately. I have some increasingly dated patches that begin to seperate user and kernel structures for the sysvipc code, and probably ought to update, complete, and commit them sometime. This makes the ABI change easier to handle. There are already ofoo() calls for sysvipc, and an interesting question is how long we have to wait before we can remove those (that was from when someone updated u_short to pid_t, I think, but didn't do the rest). 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.1020507073404.70660A-100000>