From owner-freebsd-arch Sat May 4 2:45:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 61C4A37B404; Sat, 4 May 2002 02:45:22 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g449itQ4033535; Sat, 4 May 2002 11:44:55 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Robert Watson Cc: arch@freebsd.org Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: Your message of "Sat, 04 May 2002 03:41:19 EDT." Date: Sat, 04 May 2002 11:44:55 +0200 Message-ID: <33534.1020505495@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message , Rob ert Watson writes: >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. That's not even remotely close to realistic. I think a realistic plan might look something like this: 1. Change the in-kernel types to 64 bits for each entity to change size: a) rewrite syscall entries to translate sizes. b) change size in kernel, but retain old size in userland 2. Add new syscall API a) write syscalls implementations. 3. Change userland over. a) Add #ifdef NEWAPI all over the includes so people can select which API to use. b) Create new major-revv libc which uses new API c) Leave people time to find bugs in ports etc. d) Throw the switch for good. Earliest realistic dates would be 3c on juli 1st and 3d a month later. Is that too late for 5.0-R ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message