Date: Wed, 8 May 2002 00:58:19 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@wemm.org> 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: <200205080758.g487wJtZ003208@apollo.backplane.com> References: <20020508070001.1BF6F38FD@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
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?200205080758.g487wJtZ003208>