Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: Files for all devices??
Keywords: DEUNA VAX BSD
Message-ID: <11687@dog.ee.lbl.gov>
Date: 2 Apr 91 18:48:55 GMT
References: <1991Apr1.203925.19204@sci.ccny.cuny.edu>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 22
X-Local-Date: Tue, 2 Apr 91 10:48:55 PST

In article <1991Apr1.203925.19204@sci.ccny.cuny.edu>
jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes:
>So, how come no [/dev] entry for the DEUNA ethernet card?  I realize it's
>configured as a pseudo-device ...

Actually, it is configured as a regular `device':

	device	de0	at uba? csr 0174510		vector deintr

(`vector deintr' really belongs elsewhere, but this is a completely
different topic).  The argument against a /dev entry begins with
`what would you do with it?'

(Of course, the same argument can be used against block devices, which
exist primarily to give names to an internal interface.  I occasionally
argue for /dev entries for network interfaces.  Certainly `permissions
on /dev entries' is a better approach than `magic socket options'.  Alas,
you really *do* want filters inserted over top of raw interfaces.
`Protocol stacks' make sense here but the demultiplexing becomes hairy.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov