Date: Wed, 08 May 2002 12:30:28 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Peter Wemm <peter@wemm.org> Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <6912.1020853828@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 08 May 2002 00:00:01 PDT." <20020508070001.1BF6F38FD@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20020508070001.1BF6F38FD@overcee.wemm.org>, Peter Wemm writes: >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. Uhm, that was what I tried to express with my proposal. >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. Exactly. And that means that we can ditch the MPSAFE thing in the syscall.master file, since the *_open() function will be MPSAFE nomatter what and if open() isn't MPSAFE, then open() will grab and release GIANT. >Finally, I really think the entire-new-syscall vector idea is sheer >wasteful overkill. Having looked at the number of syscalls we have to deal with I think it is the only practically passable route. I havn't heard any comments on the splitting of the #include files ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?6912.1020853828>