From owner-freebsd-arch Wed May 8 0:58:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 39F8137B406; Wed, 8 May 2002 00:58:23 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.9.1) with ESMTP id g487wJhU003211; Wed, 8 May 2002 00:58:19 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g487wJtZ003208; Wed, 8 May 2002 00:58:19 -0700 (PDT) Date: Wed, 8 May 2002 00:58:19 -0700 (PDT) From: Matthew Dillon Message-Id: <200205080758.g487wJtZ003208@apollo.backplane.com> To: Peter Wemm Cc: Poul-Henning Kamp , John Baldwin , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: <20020508070001.1BF6F38FD@overcee.wemm.org> 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 :Personally, I think this is *way* overkill. : :I think there is far more value to be had by divorcing the syscall :interfaces from the code that implements them so we can do away with the :damn stackgap stuff. : :eg: instead of open() doing the copyin *and* the body of the work, :we should have sys_open (or abi4_open, linux_open, etc) which do the pathname :copyin, any args massaging etc, and then call open() with the cleaned up :arguments. open() shouldn't have to do copyin etc. I would love to see this too. Just looking at the hell the linux syscall emulation code goes through is enough to convince me. (I don't agree with your argument against adding another syscall vector, however, because I see no other solution that is clean enough to be a reasonable replacement). :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. : :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 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message