From owner-freebsd-stable@FreeBSD.ORG Fri Jun 17 14:26:31 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3791916A41F for ; Fri, 17 Jun 2005 14:26:31 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5483043D49 for ; Fri, 17 Jun 2005 14:26:29 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j5HEQQXZ002984; Fri, 17 Jun 2005 23:56:27 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Hannes Mayer Date: Fri, 17 Jun 2005 23:56:05 +0930 User-Agent: KMail/1.8 References: <200506172159.34920.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3392028.raEsX7dRrf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506172356.12199.doconnor@gsoft.com.au> X-Spam-Score: -2.4 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: Kernel module/IPC with userland: create and write to FIFO X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 14:26:31 -0000 --nextPart3392028.raEsX7dRrf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 17 Jun 2005 23:47, Hannes Mayer wrote: > > If you read and write to it, it acts like a FIFO. > > Thanks for your reply! :-) > > Well, the reason why I want to use a true FIFO is, that data is > sampled i.e. every second and I want to write it to disk in userspace > only every minute or so. So if I add a ".d_ioctl" to "struct cdevsw" I wasn't suggesting an ioctl(), just read(). > for the device node, I have to make a function in the kernel module > for handling the userspace read request and I have to cache the > sampled data in the kernel module. I want the module to be flexible, The read() function is really quite simple, as for the caching - that can b= e=20 done in userland. > so if I don't sample at a fixed frequency (i.e. event counting) I > don't know how much data is coming in in a certain time interval and > with a FIFO I don't have to care about the data-cache size. I would suggest that you buffer it in userland. Ie have a small buffer in the kernel and have a userland process that reads= =20 from the kernel as soon as data is ready and stores it in memory.=20 Doing it this way makes it much simpler to modify your write strategy as yo= u=20 need to. It doesn't matter what the variability of the data rate is if you use=20 read/write since the userland app will spend 99% of it's time waiting in=20 select() for the kernel to tell it when new data is available. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3392028.raEsX7dRrf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCst2E5ZPcIHs/zowRAtzAAJ97v0O13TSfMU4sfWoko94zbD3voACgoQ/s b23fkseNGbJ16/L6G22IrSI= =zFiz -----END PGP SIGNATURE----- --nextPart3392028.raEsX7dRrf--