Date: Wed, 08 May 2002 01:38:06 -0700 From: Peter Wemm <peter@wemm.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020508083806.1EA9E38CC@overcee.wemm.org> In-Reply-To: <200205080758.g487wJtZ003208@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > :Finally, I really think the entire-new-syscall vector idea is sheer > :wasteful overkill. I'd much rather we had COMPAT_FREEBSD4 kernel compile > :options using the existing vector with new syscalls added in that we need > :to translate. What I saw on SVR4 was much cleaner. They dealt with > :different "struct stat"'s wit no trouble at all. You could even compile > :to the older interfaces. > > This is what I tried to do when I was messing around with time_t and > I came to regret it. There are just too many system calls that need > to be changed to simply be able to add them to the existing vector. > Take the 'stat' mess and multiply by about 20 and the result is the > mess you would get if you tried to integrate the 64 bit calls into the > existing vector. struct stat is pretty easy. Have a look at what NetBSD did. It is quite simple. http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/syssrc/sys/sys/stat.h?rev=1.41&content-type=text/x-cvsweb-markup They define the different struct stat's and use a __RENAME() macro from cdefs.h. They can even trivially compile a binary that uses their 1.2 binary interface vs their current 1.3 interface. IMHO, 'struct stat' is hardly a reason for a new syscall vector when it can be solved other ways so easily. I would not be suprised if all the others couldn't be done pretty easily too. I'm not sure that a new syscall vector will gain us much at the end of the day other than an even bigger kernel with more tables to get out of sync... This is right up there with "Hey! lets reorder ASCII so that it is more sensible!". At the end of the day we now have *two* character sets and now have the difficulty of keeping track which is which. And the end user sees nothing new, he's still got all the same keys to type with... He's not going to care all that much if it is easier to memorize the 'new-ascii' code table. At face value it looks like a good idea, but I dont any real benefit except more work that people have to do. [Note, I am *not* suggesting that we keep time_t and other types small, I am just questioning the elaborate path to get there. A cynic might wonder if somebody was getting paid by the hour for this... ] Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20020508083806.1EA9E38CC>