Date: Fri, 21 Oct 2005 14:23:52 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Konstantinos Boukis <konstantinos.boukis@kcl.ac.uk> Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation Message-ID: <Pine.GSO.4.43.0510211418280.2605-100000@sea.ntplx.net> In-Reply-To: <1129912052.435916f42500c@impmail.kcl.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Oct 2005, Konstantinos Boukis wrote: > Well, to be honest I managed to bypass the NULL fd_cdir problem by assigning a > temporary valid filedesc to curthread->td_proc->p_fd just before the invocation > to linker_load_module. > However I am curious to see the upcall solution as well. When I read that: > "When a thread blocks in the kernel, the (virtual) cpu is reallocated to > another newly created context (thread) and it is allowed to proceed back > to userland and runs a known routine with a known pointer as its > argument." (from > http://lists.freebsd.org/pipermail/freebsd-threads/2003-July/001018.html) > I understood that when a kernel thread blocks it makes an upcall to userland and > it calls the ku_func function. When ku_func accomplishes its operation then the > kernel thread is resumed so as to comply with the upcall definition of clark's > "The structuring of systems using upcalls" and Kohler's "the click modular > router". So, have I got it right or I am missing something? These set of functions are meant for user threading, not kernel initiated threading. I don't know what Clark and Kohler describe, but these functions were specifically made for allowing thread libraries to be written. If you want userland to do something based on a kernel event, traditionally userland calls into the kernel and waits for the event, then does whatever it needs to when the event occurs. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0510211418280.2605-100000>