From owner-freebsd-threads@FreeBSD.ORG Sat Oct 22 04:53:41 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 EA1D816A41F for ; Sat, 22 Oct 2005 04:53:41 +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 8924743D45 for ; Sat, 22 Oct 2005 04:53:41 +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 j9M4reFE015605; Sat, 22 Oct 2005 00:53:40 -0400 (EDT) Date: Sat, 22 Oct 2005 00:53:39 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Konstantinos Boukis In-Reply-To: <1129939027.43598053423cb@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: Sat, 22 Oct 2005 04:53:42 -0000 On Sat, 22 Oct 2005, Konstantinos Boukis wrote: > I tried not to bombard you with all the information of what I am doing bu= t 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 protocol= s > (i.e. like Mobile IP) offered by the network. In my implementation the ke= rnel > identifies the offered protocol and installs the appropriate modules. There are other examples to look at, like devd. Actually, I don't see why you can't just use devd. From devd(8): "Another example would be for devd to use a table to locate and load vi= a kldload(8) the proper driver for an unrecognized device that is added = to the system." > >From my perspective I am more concerned for preserving the theoretical > constrains (i.e. the model of computation) than the practical ones. Of co= urse I > understand your perspective as well; you are developing an operating syst= em and > your concern is to make it as stable as possible. But let=92s assume that= a > userland stack does exist and is valid and mapped, can a kernel thread su= spend, > call the function pointed by ku_func in userland and then resume in kerne= l > space? At the end of the day it is interesting and good fun to play aroun= d with > those things, which I guess is our concern in common. You might be able to get it to work, but it would probably take more work to get it to work the way you want it to. It would still be easier to make a simple device driver and use ioctl(). Again, look at devd. --=20 DE