Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 May 2002 18:51:19 +0200
From:      Eivind Eklund <eivind@FreeBSD.ORG>
To:        Robert Watson <rwatson@FreeBSD.ORG>
Cc:        John Baldwin <jhb@FreeBSD.ORG>, Matthew Dillon <dillon@apollo.backplane.com>, arch@FreeBSD.ORG, Poul-Henning Kamp <phk@FreeBSD.ORG>
Subject:   Re: syscall changes to deal with 32->64 changes.
Message-ID:  <20020507185119.C11452@phoenix.dmnstech.net>
In-Reply-To: <Pine.NEB.3.96L.1020507112126.76283L-100000@fledge.watson.org>; from rwatson@FreeBSD.ORG on Tue, May 07, 2002 at 11:28:26AM -0400
References:  <XFMail.20020507103320.jhb@FreeBSD.org> <Pine.NEB.3.96L.1020507112126.76283L-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 07, 2002 at 11:28:26AM -0400, Robert Watson wrote:
> My feeling on a strategy resembles the one phk proposed...
> 
> (1) Someone does a first pass.  Since Kirk and Poul-Henning are doing some
>     of this anyway, they'd be good candidates.  They do what they need,
>     but don't get carried away.
> 
> (2) They commit this, but it does not become the default.  How to handle
>     #includes is an interesting question, perhaps using some new_foo_t
>     until the switchover is done.  Or foo64_t or the like.  Throwing a
>     date at this is a good idea.  phk's dates looked good -- perhaps
>     mid-June or late June.
> 
> (3) We have a window where other developers now take care of the things
>     they care about in the new ABI.   For example, I'd be happy to pick up
>     the sysvipc work to switch to uid_t and gid_t.  Depending on our
>     definition of "get carried away" above, this might be a good time to
>     update the time-related types.
> 
> (4) The switch is thrown.  This is the second date of interest.  We don't
>     want to let this get beyond the end of July, so we can cut DP3 (which
>     would be inevitable with a new ABI) with the new ABI and get decent
>     testing. 

Somewhere between 0 and 3.5 we should have an

X) Write a list of proposed changes to the syscalls by just going through the
syscalls list and adding proposed changes, based on public discussion.

I think the right thing to do might be to just make a copy of syscalls.master
and let people commit suggested improvements, and then post it to arch for
discussion after a while (e.g, 3 weeks.)

Eivind.

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?20020507185119.C11452>