Re: Userapi, Reflection

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:* Lewis, Todd (todd.lewis@xxxxxx) wrote:
:> Maybe I'm misunderstanding, I don't understand why code needs to be in the
:> kernel.  Why not just, at run-time, link in the appropriate
:> syscall-decoder/rewriter depending on the personality of the binary?  New
:> syscalls for linux would just require updating
:> /lib/libpersonality_linux.so...
:
:I like this idea. The more we can push into userspace, the better.
:
:> Also, Matt, when you're talking about 0x80 being a userspace interrupt,
:> would that require rewriting the binary, valgrind-style, or is there some
:> hardware trick that could be used, or is there some other way?  My
:> understanding of x86 is that 0x80 always context-switches into the kernel,
:> but I am a novice in such matters.
:
:I don't think that apps need to be rewritten. int 0x80 can always be
:hooked up to do something else (like figure out which syscall is called
:from which personality, and then send the required dragonfly message).
:
:Of course, IANAAH (asm hacker), so I could be completely wrong about
:this.
:
:Cheers,
:Emiel
:-- 

   Just to be clear, the personality code would be run in userspace...
   but the kernel would have to be responsible for mapping it since the
   two situations are: (1) That the program itself will have no idea that
   it's syscalls are being emulated in userland or (2) That the program is
   aware of the existance of the personality mdoule and is able to call it
   directly.

   --

   What I would also like to do is 'fix' system calls which return structures,
   like gettimeofday(), fstat(), and so forth... instead of returning
   structures they would return a resource array.  The personality code
   would then scan the resource array to load the C structures that the user
   program expects.

   This would allow us to add and and remove elements returned by the kernel
   without 'breaking' user programs.  For example, the kernel could add
   extent information to fstat, and so forth.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>