DragonFly kernel List (threaded) for 2003-08
Re: More syscall messaging commits, and some testing code as well.
On Mon, Aug 11, 2003 at 07:45:21PM -0700, Matthew Dillon wrote:
> I just committed another bunch of syscall messaging stuff, plus I
> also committed some test code for it in /usr/src/test. This is ad-hoc
> test code and committers are welcome to throw in their own testing
> code in that directory willy-nilly :-)
> In this commit I have managed to asynchronize nanosleep(), but there
> are still a bunch of issues that have to be worked through. For
> example, we need resource limits on the number of outstanding system
> calls we allow to be in-progress and there needs to be a mechanism to
> abort system calls which are in-progress when a program is killed.
Will the system calls be like atomic transactions? I.e., will it
be possible to ^C a program, and the currently executing system
call will rollback whatever it was doing?
I guess what I am asking might be a little superficial...
> The question we face is whether it makes sense to separate the phases
> in order to isolate the execution phase, which would allow system calls
> to be made 'from' a kernel thread as a matter of course, rather then as
> a special case.
IMHO, it will be a flexibility thing; to reinvent the wheel.
That is, someone (hint hint :) might want to use the accept()
call inside the kernel, without reinventing the wheel.
Ofcourse, this is (using accept() in kernel) something which not
everyone is going to do, but it will be flexbility which can be
provided, if someone choose to do so.
Hiten M. Pandya