From owner-freebsd-arch Thu May 9 5:54:18 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 B2C8837B40C for ; Thu, 9 May 2002 05:54:12 -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 g49CreHA026701 for ; Thu, 9 May 2002 14:53:40 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@FreeBSD.ORG Subject: New ABI (32->64) [take two]... Date: Thu, 09 May 2002 14:53:40 +0200 Message-ID: <26700.1020948820@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 So, Status: 1. Yes, 32->64 brings sufficient havoc that a new ABI is a good idea. 2. Yes, we have at least one way to mark the ELF binaries as using the new ABI. 3. TBD: name/numbering of new ABI. 4. Yes, kernel side should be split into $ABI_$syscall() which does the copyins and type conversions and sc_$syscall() which operates entirely in kernel native data types. 5. TBD: Split header files in src/sys/sys into src/sys/include and src/sys/$ABI. src/$arch/include into src/$arch/include and src/$arch/$ABI to separate userland/syscall arguments from kernel native arguments. 6. TBD: Review and approval process for new syscall definition. 7. TBD: Decision process if/when -current/5.0 switches to new API (TBD: To Be Determined == still outstanding) Is this correctly interpreted ? -- 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