From owner-freebsd-hackers  Mon Dec 22 01:48:15 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA12603
          for hackers-outgoing; Mon, 22 Dec 1997 01:48:15 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from acroal.com (firewall0.acroal.com [209.24.61.154])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA12598
          for <hackers@FreeBSD.ORG>; Mon, 22 Dec 1997 01:48:10 -0800 (PST)
          (envelope-from jamil@acroal.com)
Received: from localhost (jamil@localhost)
	by acroal.com (8.8.8/8.8.7) with SMTP id BAA02697;
	Mon, 22 Dec 1997 01:47:58 -0800 (PST)
	(envelope-from jamil@acroal.com)
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) 
In-Reply-To: <199712220844.TAA00494@word.smith.net.au>
Message-ID: <Pine.BSF.3.96.971222013840.2683A-100000@acroal.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


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
> 
> 
>