From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 19:18:12 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 D3DC516A41F; Fri, 21 Oct 2005 19:18:12 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by mx1.FreeBSD.org (Postfix) with SMTP id BA58143D45; Fri, 21 Oct 2005 19:18:11 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) X-VirusChecked: Checked X-Env-Sender: konstantinos.boukis@kcl.ac.uk X-Msg-Ref: server-10.tower-82.messagelabs.com!1129922289!24500313!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [137.73.2.214] Received: (qmail 5472 invoked from network); 21 Oct 2005 19:18:09 -0000 Received: from outbound.kcl.ac.uk (137.73.2.214) by server-10.tower-82.messagelabs.com with SMTP; 21 Oct 2005 19:18:09 -0000 Received: from relay3.kcl.ac.uk ([137.73.2.218] helo=Hazel) by outbound.kcl.ac.uk outbound with esmtp (TLSv1:DHE-RSA-AES256-SHA:256) id 1ET2Oe-0005Md-Sc; Fri, 21 Oct 2005 20:17:44 +0100 Received: from elder.kcl.ac.uk ([137.73.2.27] helo=localhost) by Hazel smtphack with esmtp id 1ET2OW-0002Fs-KD; Fri, 21 Oct 2005 20:17:38 +0100 Received: from host86-129-77-190.range86-129.btcentralplus.com (host86-129-77-190.range86-129.btcentralplus.com [86.129.77.190]) by impmail.kcl.ac.uk (IMP) with HTTP for ; Fri, 21 Oct 2005 20:17:36 +0100 Message-ID: <1129922256.43593ed0727ef@impmail.kcl.ac.uk> Date: Fri, 21 Oct 2005 20:17:36 +0100 From: Konstantinos Boukis To: Daniel Eischen References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-KCLOriginating-IP: 86.129.77.190 X-KCLSpamScore: 0 X-KCLRealSpamScore: 0.0 X-KCLZStatus: 0 X-KCLSpamReport: X-KCL-MailScanner: Found to be clean X-MailScanner-From: konstantinos.boukis@kcl.ac.uk Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 19:18:13 -0000 In Clark’s and Kohler’s definition for upcall, the function that initiates it waits for the upcalled function to finish its operation so as to resume. I could indeed employ a mechanism with signals between the kernel and the userland process but that would break the above definition since the kernel after wakeup() will continue its operation without waiting the userland process to finish (OK, I could then put the kernel thread to sleep and resume it from the userland, but this seems to me very sloppy programming). Anyway, just out of curiosity, is there a way for a kernel thread to invoke the userland function pointed by ku_func? (provided that a mailbox is already assigned to the kse from a userland kse_create invocation) Quoting Daniel Eischen : > 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 > > -- Konstantinos Boukis konstantinos.boukis@kcl.ac.uk