Date: Tue, 7 May 2002 12:31:13 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: John Baldwin <jhb@FreeBSD.org>, arch@FreeBSD.org, Poul-Henning Kamp <phk@FreeBSD.org> Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <200205071931.g47JVDh84057@apollo.backplane.com> References: <Pine.NEB.3.96L.1020507112126.76283L-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:> 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
I think the one big advantage with having a new syscall vector is
precisely the fact that the new ABI can be worked on without effecting
the existing system. Internal system support that is still 32 bits
winds up being straight-up in the old syscall vector and extended out
in the new, and internal system support that has been changed to 64
bits winds up being truncated in the old syscall vector and straight
up in the new. Either way we are able to maintain ABI compatibility for
both syscall vectors even if it takes months to convert all the kernel
subsystems to the new sizes.
This seems to infer that the work will not directly interfere with 5.0R,
even if it is not 100% complete by the release. That would make the
work 'a go' in my book.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200205071931.g47JVDh84057>