From owner-freebsd-threads@FreeBSD.ORG Fri Oct 21 23:57:43 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 7EF0D16A41F; Fri, 21 Oct 2005 23:57:43 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A68743D45; Fri, 21 Oct 2005 23:57:42 +0000 (GMT) (envelope-from konstantinos.boukis@kcl.ac.uk) X-VirusChecked: Checked X-Env-Sender: konstantinos.boukis@kcl.ac.uk X-Msg-Ref: server-11.tower-83.messagelabs.com!1129939059!29704146!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [137.73.2.214] Received: (qmail 2125 invoked from network); 21 Oct 2005 23:57:39 -0000 Received: from outbound.kcl.ac.uk (137.73.2.214) by server-11.tower-83.messagelabs.com with SMTP; 21 Oct 2005 23:57:39 -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 1ET6l8-0007UV-UC; Sat, 22 Oct 2005 00:57:14 +0100 Received: from elder.kcl.ac.uk ([137.73.2.27] helo=localhost) by Hazel smtphack with esmtp id 1ET6l1-0005RX-DU; Sat, 22 Oct 2005 00:57:08 +0100 Received: from host86-129-71-207.range86-129.btcentralplus.com (host86-129-71-207.range86-129.btcentralplus.com [86.129.71.207]) by impmail.kcl.ac.uk (IMP) with HTTP for ; Sat, 22 Oct 2005 00:57:07 +0100 Message-ID: <1129939027.43598053423cb@impmail.kcl.ac.uk> Date: Sat, 22 Oct 2005 00:57:07 +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.71.207 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 23:57:43 -0000 I tried not to bombard you with all the information of what I am doing but it seems inevitable ;-). I am working on a theoretical research project and the goal is to develop a mobile terminal (e.g. one that changes network continuously) that will be able to adapt to the offered mobility protocols (i.e. like Mobile IP) offered by the network. In my implementation the kernel identifies the offered protocol and installs the appropriate modules. >From my perspective I am more concerned for preserving the theoretical constrains (i.e. the model of computation) than the practical ones. Of course I understand your perspective as well; you are developing an operating system and your concern is to make it as stable as possible. But let’s assume that a userland stack does exist and is valid and mapped, can a kernel thread suspend, call the function pointed by ku_func in userland and then resume in kernel space? At the end of the day it is interesting and good fun to play around with those things, which I guess is our concern in common. Quoting Daniel Eischen : > On Fri, 21 Oct 2005, Konstantinos Boukis wrote: > > > 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). > > 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 invoke > 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. > > -- > DE > > -- Konstantinos Boukis konstantinos.boukis@kcl.ac.uk