Date: Tue, 7 May 2002 11:28:26 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: 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: <Pine.NEB.3.96L.1020507112126.76283L-100000@fledge.watson.org> In-Reply-To: <XFMail.20020507103320.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 May 2002, John Baldwin wrote:
> Right. I would like to use the ELF_ABI_OSVERSION thingie, but according
> to O'Brien it violates the ELF spec to use any value other than 0. But
> then why does it exist if we can't use it? :( One idea being thrown
> about is that for the new ABI (It would be FreeBSD ABI 2) there would be
> a syscall at syscall 0 that would never change that could be used to
> select what "minor" version of the ABI you wanted to use, so if we
> wanted to add a new ABI at some point in the future we could stick that
> syscall in crt.c (or whatever the proper startup file is) to change to
> ABI 2.1 or 2.2 or something. However, for the current change, I think
> bumping the ELF OS version and adding a new ABI front-end for ABI 2 is
> the way to go.
>
> Another advantage of this is that if our tools handle the OS version bit
> properly, we can actually not have to worry about much of a flag day.
> Instead we can gradually add the new ABI and support for it and then
> just quietly throw the switch to change the default ABI in current one
> day. Old binaries would still run fine. The only tricky part is for
> libc.so since you would really need two version of it (unless we also
> bumped to libc.so.6 for this..) and we would need to make sure we
> linked to the right OSVERSION of the lib when doing runtime linking,
> whcih could get ugly.
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.
> I think we can gradually overhaul it internally in the kernel before we
> throw the switch to turn it on by default since all we would be breaking
> would be test binaries and not "real" ones. Once the new ABI is golden,
> then we would throw the switch to change the default.
Yeah, if we can do that, would be good. BTW, since this is -current, I'm
not sure we need to be too careful with shared library versions, but it
does raise the question how we have all this co-exist. Will oldabi and
newabi live together in /usr/lib, or should we be considering something
like /usr/lib/aout?
> I'm also not sure if we shouldn't wait to do this until 6.0.
Well, that's the big question, really. If we can do it in the time frame,
why wait, as they say :-). If we can't, then it's a 6.0 thing. 5.0 is a
nice breaking point -- we're ripping up so much anyway, and we'd like to
get the ABI changes for UFS2 in. But if the schedule isn't realistic,
then we can't -- slipping 5.0-release any further isn't something I want
to let happen.
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.1020507112126.76283L-100000>