Date: Tue, 29 Aug 1995 06:01:16 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, gibbs@freefall.FreeBSD.org Cc: hackers@freefall.FreeBSD.org Subject: Re: 16, 32, and 64bit types? Message-ID: <199508282001.GAA12132@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>We have u_int32_t etc. in <sys/types.h> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508282001.GAA12132>