Date: Mon, 22 Dec 1997 01:47:58 -0800 (PST) From: "J. Weatherbee - Senior Systems Architect" <jamil@acroal.com> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: Am I off my rocker? (/dev/tick device) Message-ID: <Pine.BSF.3.96.971222013840.2683A-100000@acroal.com> In-Reply-To: <199712220844.TAA00494@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
1) I realize that (/dev/tick). However, the "clock" is a device, and in the UNIX spirit of things should also be a file. No? In this same way, I don't really see why any of the /dev/mem devices are necessary? All of those things could be accomplished through system calls. In that way /dev/null and /dev/zero are pretty useless, I mean what do they really achieve that you couldn't do in C code? 2) On the vectorized i/o, think about processes multiplexing with say 1000 - 2000 descriptors. 3) Your pretty conservative, sometime I wonder if maybye you wouldn't be happier with a 10 year old copy of AT&T UNIX? On Mon, 22 Dec 1997, Mike Smith wrote: > > for read. I may be dealing with 64 or so descriptors, but I thought it > > might be useful to have a /dev/tick pseudo device that would come ready > > for i/o say 10-100 times a second (depending on an ioctl). So suppose you > > open this device, and ioctl() it to 10 hertz, if you went into select() it > > would return ~100ms after opening the read ready on the /dev/tick fd. When > > you call read on /dev/tick, you get a unsigned int representing the number > > of microseconds (or alternately milliseconds) elapsed since the descriptor > > was opened. > > Try 'man setitimer' and 'man gettimeofday'. There's nothing you're > suggesting that can't already be done with those two. > > mike > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971222013840.2683A-100000>