Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: more exabyte questions
Message-ID: <95582@sgi.sgi.com>
Date: 5 Apr 91 02:26:01 GMT
References: <1991Apr4.202436.25620@helios.physics.utoronto.ca>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 31

In article <1991Apr4.202436.25620@helios.physics.utoronto.ca>, sysmark@physics.utoronto.ca (Mark Bartelt) writes:
>  ...
> How come?  Specifically, why is this particular class of special files treated
> differently from nearly everything else?  For example, if I do
> 
> 	MAKEDEV t3270
> 
> it just goes ahead and makes the appropriate special files, irrespective of
> whether or not I actually have an IBM 3270 interface installed on my IRIS.
> This is actually a nice feature, since I can ensure that the special files
> I want are there in advance, in anticipation of a device actually getting
> installed.  Not so, for some reason, with SCSI tapes, at least in certain
> circumstances.  The tps*v files get created only if "mt -t whatever status"
> reports that there's an exabyte there.  Why?

Because /dev is fat, bloated, bulging, and and ugly.  Because there are
important, hallowed UNIX commands that stat(2) names in /dev until they
find what they want, with obvious performance synergisms with the current
size of /dev.  Because we have not figured out a good mechinism to create
the nodes only for the hardware that actually exists on the system.
Because it's practically impossible to find a device name in /dev by
visually scanning `ls -l /dev`.


(Sorry about the babble.  This issue has many old connotations around here.)



Vernon Schryver,  vjs@sgi.com