On 31-Jul-2003 Ryan Sommers wrote:
When making a system call to the kernel why is it necessary to push the
syscall value onto the stack when you don't call another function?
Example:
access.the.bsd.kernel:
int 80h
ret
func:
mov eax, 4; Write
call access.the.bsd.kernel
:You need 8K for this, minimally: 4K that's RO user/RW kernel and
:4K that's RW user/RW kernel. You can use it for things like zero
:system call getpid/getuid/etc..
:
:It's also worth a page doubly mapped, with the second mapping with
:the PG_G bit set on it (to make it RO visible to user space
On Fri, 2003-08-01 at 02:59, Terry Lambert wrote:
Personally, I like to look at the Linux register-based passing
mechanism in the same light that they look at the FreeBSD use
of the MMU hardware to assist VM, at the cost of increased
FreeBSD VM system complexity (i.e. they think our VM is too
Maybe, but they also support a lot of MMU-less architectures, so it may
have made things simpler for them to not depend on MMU. I wonder if NUMA
had any bearing on that as well...
No. The initial design of their VM greatly preceded NUMA and uCLinux. It
actually makes the system less portable
On Sat, 2003-08-02 at 16:23, Kip Macy wrote:
table layout differs from the default. The introduction to the UVM thesis has
some good points in this regard.
UVM thesis?
(I am subscribed to list.)
--
Shawn [EMAIL PROTECTED]
http://drevil.warpcore.org/
UVM was the VM system that replaced the old Mach style VM in NetBSD and (I
believe) OpenBSD. FreeBSD has already cleaned up a lot of the problems that
UVM addresses. However, there are still some things that could be done to
make map passing easier, which I believe would make zero-copy support
It's a toss up. Linux's use of registers for syscall args is not
a panacea, because many system calls require more then just the basic
call-used registers which means the linux userland code has to save
and restore those registers on the stack anyway. And we won't even
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
: Additionally, the mechanism can
: be extended to support chained system calls (i.e. issue several system
: calls at once), and transactional sequences.
VMS has done this for a long time. :-) All of
Matthew Dillon wrote:
I think the ultimate performance solution is to have some explicitly
shared memory between kerneland and userland and store the arguments,
error code, and return value there. Being a fairly small package of
memory multi-threading would not be an issue as
Ryan Sommers wrote:
When making a system call to the kernel why is it necessary to push the
syscall value onto the stack when you don't call another function?
The stack is visible in both user space and kernel space; in
general, the register space won't be, unless you are on an
architecture
When making a system call to the kernel why is it necessary to push the
syscall value onto the stack when you don't call another function?
You have to push anything the size of an address. Because the call return
pushes the return adress on the stack. The 1st and 3rd both push 4 bytes,
so
On Thu, Jul 31, 2003 at 04:12:27PM -0400, Ryan Sommers wrote:
When making a system call to the kernel why is it necessary to push the
syscall value onto the stack when you don't call another function?
Example:
access.the.bsd.kernel:
int 80h
ret
func:
mov eax, 4; Write
call
12 matches
Mail list logo
