DragonFly BSD
DragonFly kernel List (threaded) for 2005-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: patch #4 (Re: patch #3 (Re: The time has come for a kernel interfacing library layer))

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Wed, 11 May 2005 20:48:34 +0200
Mail-followup-to: kernel@crater.dragonflybsd.org

On Wed, May 11, 2005 at 11:34:00AM -0700, Matthew Dillon wrote:
>      For example, adding a procedural call layer introduces numerous
>      problems...  if we try to propogate the carry bit back (the carry bit
>      determines whether a system call has failed or succeeded), then it
>      complicates our ability to write C 'override' code for a system call. 

As I said before we will end up with a procedural layer in between anyway,
because we can't handle mixed ABI in dynamic programs otherwise.
That's not necessarily a problem, as long as libraries don't reexport
certain structures. It's a difficult problem nonetheless.

>      If we push an errno pointer instead that means we have to *calculate*
>      the errno pointer first, which costs a lot of cycles right smack in
>      the middle of the critical system call path.
>      libc can't even push a function pointer for error handling in the PIC
>      case without it costing a lot of cycles.

Why can't we use a variadic function like calling convention?
In the kernel we end up allocating a structure and reading the arguments in
anyway, so the pointer to the first argument could be passed in directly.
After returning from the syscall layer, we could do (almost) the same as
the current syscall code, just replacing the kerncall with a normal
function call.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]