Date: Sat, 22 Oct 2005 00:53:39 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Konstantinos Boukis <konstantinos.boukis@kcl.ac.uk> Cc: freebsd-threads@freebsd.org Subject: Re: kernel upcall documentation Message-ID: <Pine.GSO.4.43.0510220045350.5149-100000@sea.ntplx.net> In-Reply-To: <1129939027.43598053423cb@impmail.kcl.ac.uk>
index | next in thread | previous in thread | raw e-mail
On Sat, 22 Oct 2005, Konstantinos Boukis wrote:
> 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.
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 via
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 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.
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.
--
DE
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0510220045350.5149-100000>