From owner-freebsd-hackers Wed Aug 27 01:02:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA18134 for hackers-outgoing; Wed, 27 Aug 1997 01:02:59 -0700 (PDT) Received: from wong.rogerswave.ca (wong.rogerswave.ca [204.92.17.32]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA18129 for ; Wed, 27 Aug 1997 01:02:56 -0700 (PDT) Received: (from wong@localhost) by wong.rogerswave.ca (8.8.5/8.7.3) id DAA00667; Wed, 27 Aug 1997 03:01:03 -0400 (EDT) Date: Wed, 27 Aug 1997 03:01:02 -0400 (EDT) From: Ken Wong X-Sender: wong@wong.rogerswave.ca Reply-To: wong@rogerswave.ca To: Simon Shapiro cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Calling a Daemon from the Kernel - How? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I got something similar to what you are discribing. but not exactly... it is more like the Send-Receive-Reply found in QNX ( microkernel OS). it is basically allow a process passing message another process. But then you can make a kernel to fake a dummy kernel process and talk to the daemon. with this machanism, one can built a microkernel freebsd if the will is there. Maybe I should ask the list if there is any demand for the send-receive-reply be included in the kernel for future development. On Mon, 25 Aug 1997, Simon Shapiro wrote: > Hi Y'all; > > How do I write a program that gets called from the kernel. > I know how to write a program that call the kernel :-) > I even know (some of you may argue with this) how to write a kernel driver > that gets called form userspace :-) > > I want to write a daemon (or whatever) that gets called by the kernel to do > sone dirty work I do not think belongs in the kernel. > > In Linux, there is a kerneld with its attendant protocol. > In other O/S's I had a messy procedure that posts a read to the device, > waiting to be called. As soon as it is called, it posts another READ. > One can get fancy with this, but the serializing implied by this mechanism > is not always a bad thing. > > Any ideas or suggestions are very welcome. > > Simon > > >