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

Re: More syscall messaging commits, and some testing code as well.

From: Hiten Pandya <hmp@xxxxxxxx>
Date: Tue, 12 Aug 2003 03:25:48 -0700

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 :-)

	Cool! ;-)
>     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
hmp@xxxxxxxxxxx, hmp@xxxxxxxx

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