From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 18:23:54 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4550016A41F for ; Fri, 21 Oct 2005 18:23:54 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBDEC43D45 for ; Fri, 21 Oct 2005 18:23:53 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id j9LINqcX004835; Fri, 21 Oct 2005 14:23:52 -0400 (EDT) Date: Fri, 21 Oct 2005 14:23:52 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Konstantinos Boukis In-Reply-To: <1129912052.435916f42500c@impmail.kcl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 18:23:54 -0000 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