DragonFly kernel List (threaded) for 2005-05
Re: patch #4 (Re: patch #3 (Re: The time has come for a kernel interfacing library layer))
On Thu, May 12, 2005 at 10:03:24AM -0700, Matthew Dillon wrote:
> :But we don't return 64bit values. Only 32 bit. Why can't it simply return
> :errno in one register and the normal return value in the other? It would
> :save the whole carry register dance.
> We sure do return 64 bit values! lseek().
I only checked the normal definition, sorry. Yeah, this is a problem.
> :> translated system call might require more arguments. For another,
> :> some sort of conversion is already going to have to be done and the
> :> cost of copying a couple of 32 bit ints becomes zip relative to the
> :> other work that must occur.
> :OK, so we depricate the generic syscall?
> No. Most system calls won't need translation. We don't want to have
> to manually write wrappers for 300 system calls! A generic syscall
> generator is still very much necessary.
I meant syscall(2).
> :> The RTLD could set up a dummy TCB (with *NO* TLS storage attached).
> :> Poof, problem solved. That would allow the RTLD to use the same syscall
> :> layer that the program uses, too.
> :The RTLD would have to do that every time it is called, it would have to
> :reset it before any signal, that's a lot of requirements.
> :This completely ignores the issues of reentrancy in RTLD, of course.
> I'm not sure what you mean here. The RTLD would only need to set up
> a dummy TCB at init time. After that there will always be a TCB,
> either the original dummy one that the RTLD set up, or the one that
> libc sets up, or pthreads or libthread_xu. There will always be a TCB,
> and *ALL* of the TCBs have to use our structural definition for the TCB
> in order to work at all... not just for errno handling, but simply for
> TLS support to work as expected.
Yes, but they point to an errno which is not RTLD's errno.