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.b
: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 at
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
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
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
menti
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 cle
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/
___
> 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 portabl
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 t
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 wi
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; Wri
> 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 th
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
; End
Works. However:
func:
mov eax, 4; Write
in
13 matches
Mail list logo
