From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 7 14:41:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0B9816A4CE; Fri, 7 Nov 2003 14:41:02 -0800 (PST) Received: from goose.mail.pas.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2160743FB1; Fri, 7 Nov 2003 14:41:02 -0800 (PST) (envelope-from jtoung@arc.nasa.gov) Received: from h-68-164-88-108.snvacaid.dynamic.covad.net ([68.164.88.108] helo=there) by goose.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AIFHp-0001C0-00; Fri, 07 Nov 2003 14:41:01 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Jerry Toung Organization: ARC To: Robert Watson Date: Fri, 7 Nov 2003 14:41:22 -0800 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200311071441.22114.jtoung@arc.nasa.gov> X-ELNK-Originating-IP: 68.164.88.108 cc: hackers Subject: Re: sending messages, user process <--> kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2003 22:41:03 -0000 Thank you very much for the inputs. On Friday 07 November 2003 01:53 pm, Robert Watson wrote: > On Fri, 7 Nov 2003, Jerry Toung wrote: > > I am trying to do asynchronous send/receive between a user process th= at > > I am writing and a kernel module that I am also writing. I thought > > about implementing something similar to unix routing socket, but I wi= ll > > have to define a new domain and protosw. Beside that idea, what else > > would you suggest? > > This is actually somewhat of a FAQ, since it comes up with relative > frequency. I should dig up my most recent answer and forward that to y= ou, > but the quicky answers off the top of my head are: > > (1) One frequent answer is a pseudo-device -- for example, /dev/log > buffers kernel log output for syslogd to pick up asynchronously. A= rla > and Coda both use pseudo-devices as a channel for local procedure > calls to/from userspace to support their respective file systems us= ing > userspace cache managers. > > (2) Have the kernel open a file system FIFO and have the process on tha= t > FIFO. The client-side NFS locking code uses /var/run/lock to ship > locking events to a userspace rpc.lockd. However, responses from > rpc.lockd are then delivered to the kernel using a system call > synchronously from the user process, as opposed to via a FIFO. > > (3) The routing socket approach can work quite well, especially if you > need multicast semantics for messages, not to mention well-defined > APIs for managing buffer size, etc. Another instance of this approa= ch > is PF_KEY, used for IPsec key management. As you point out, it > requires digging into other code and a fair amount of implementatio= n > overhead. > > (4) You can have kernel code create and listen on sockets in existing > domains, including UNIX domain sockets and TCP/IP sockets. The NFS > client and server code both make use of sockets directly in the > kernel for RPCs. > > Some of the particularly nice benefits of (2) and (4) is that it's easy= to > implement userspace test code, since the fifo/socket is just used as a > rendezvous and doesn't care if the other end is in kernel or not. > Likewise, the blocking/buffering/... semantics are quite well defined, > which means you won't be tracking down wakeups, select semantics, threa= d > behavior and synchronization, etc, as you might do in (1). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories