From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 19:38:32 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 5E92916A41F for ; Fri, 21 Oct 2005 19:38:32 +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 DE69C43D48 for ; Fri, 21 Oct 2005 19:38:31 +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 j9LJcUbm023117; Fri, 21 Oct 2005 15:38:30 -0400 (EDT) Date: Fri, 21 Oct 2005 15:38:30 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Konstantinos Boukis In-Reply-To: <1129922256.43593ed0727ef@impmail.kcl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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 19:38:32 -0000 On Fri, 21 Oct 2005, Konstantinos Boukis wrote: > In Clark=92s and Kohler=92s definition for upcall, the function that init= iates 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 kern= el > after wakeup() will continue its operation without waiting the userland p= rocess > 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). I think it would be better to have userland (daemon) initiate things if you indeed need to have userland do stuff. What you want to do seems very much worse. How do you know there is a userland process waiting to do anything unless the userland first calls into the kernel? If that's the case, then just put the userland process (thread) to sleep via either read(), write(), ioctl(), kqueue(), or whatever until your event happens. Why is abusing the KSE functions any better? > Anyway, just out of curiosity, is there a way for a kernel thread to invo= ke the > userland function pointed by ku_func? (provided that a mailbox is already > assigned to the kse from a userland kse_create invocation) There is not necessarily a userland stack if it is a pure kernel thread. If you are trying to pass a stack from another userland process (thread), there is no guarantee that the process still exists and the stack is valid, mapped, and valid for the kernel thread to use. I'm not sure what it is you are trying to do, but I think you're looking at it the wrong way. --=20 DE