From owner-freebsd-hackers Mon Aug 28 13:03:45 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id NAA23145 for hackers-outgoing; Mon, 28 Aug 1995 13:03:45 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id NAA23137 ; Mon, 28 Aug 1995 13:03:41 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA12132; Tue, 29 Aug 1995 06:01:16 +1000 Date: Tue, 29 Aug 1995 06:01:16 +1000 From: Bruce Evans Message-Id: <199508282001.GAA12132@godzilla.zeta.org.au> To: bde@zeta.org.au, gibbs@freefall.FreeBSD.org Subject: Re: 16, 32, and 64bit types? Cc: hackers@freefall.FreeBSD.org Sender: hackers-owner@FreeBSD.org Precedence: bulk >>We have u_int32_t etc. in (actually in >>... >Yes, I meant u_int32_t. Any reason sys/types.h doesn't use them >to express the other types? This is how it is done in NetBSD. NetBSD apparently wanted to fix the type sizes for portability. We haven't needed needed to do that yet. 4.4lite apparently attempted to fix most of the sizes by using `long' even where `int' would be more natural (e.g., for pid_t). Both approaches are wrong. Kernel types and disk types should not correspond directly to the application interface to those types. E.g., Type FreeBSD NetBSDr1994/12) Right ---- ------- --------------- ----- min_dev_t - - u_int32_t disk_dev_t - - u_int32_t kernel_dev_t - - kernel_promote(min_dev_t) dev_t unsigned long int32_t user_promote(min_dev_t) min_pid_t - - u16_t (for PID_MAX = 30000) kernel_pid_t - - kernel_promote(min_pid_t) pid_t long int32_t user_promote(min_pid_t) where user_promote(foo_t) is a good promotion of foo_t with the reference user compiler and kern_promote(foo_t) is a good promotion of foo_t with the current kernel compiler. Application binary compatibility is given by fixing the refererence user compiler. Efficiency is given by choosing good promotions. Bruce