Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Apr 95 11:41:28 MDT
From:      terry@cs.weber.edu (Terry Lambert)
To:        pritc003@maroon.tc.umn.edu (Mike Pritchard)
Cc:        rgrimes@gndrsh.aac.dev.com, hackers@freefall.cdrom.com
Subject:   Re: [DEVFS] your opinions sought!
Message-ID:  <9504191741.AA19086@cs.weber.edu>
In-Reply-To: <199504190842.DAA04273@mpp.com> from "Mike Pritchard" at Apr 19, 95 03:42:28 am

next in thread | previous in thread | raw e-mail | index | archive | help
> I have a question:  what does the devfs file system get me, and
> why would I ever want to use it?  From what I've seen so far, it just
> looks like a complicated way to access my /dev/* files.


1)	Automatic generation and removal of nodes for dynamically
	loadable and unloadable devices.

2)	Automatic generation/removal of devices on bus reset.  For
	instance, attach a device to the SCSI device chain, or
	power on a tape on the chain that was not powered on at
	boot time, and it can be made available.  The existance
	of a device file is no longer an ambiguous marker.

3)	Automatic generation/removal of devices as PCMCIA cards are
	inserted or extracted.  You can't have a /dev/tty/02 unless
	you plug in your PCMCIA modem card, for instance, and you
	want that to go away and be replaced by /dev/ed/00 when
	you yank it out and stick in your pcmcia network card.  Or
	/dev/dsk/??? and /dev/rdsk/??? when you yank that out and
	replace it with an Adaptec PCMCIA SCSI controller, or a
	type II or type III disk drive card.

4)	Remote boot from non-BSD systems.  One of the main problems
	in making a diskless system boot BSD right now is the
	inability of the specfs on the host system to represent
	BSD file system device adequately.  DO NOT UNDERESTIMATE
	THE IPORTANCE OF THIS ITEM!

5)	OpenNet style device export ove the net.  This will work
	with a devfs because the device will still be a remote
	reference instead of a local reference in the local specfs.
	You want to access a remote modem?  Open it.

6)	Protection against trojan-related attacks made by previous
	cracking that changed device permissions.  Permission
	changes are no longer persistant over reboot (if you want
	to open up a hole, you will have to explicitly do it in
	your /etc/rc).

7)	Protection against some types of mistakes.  I have more
	than once created a file in my /dev directory instead of
	writing a device simply because I made a typo.  Such file
	creates are no longer permissable.

8)	The "specfs" (an obscene hack in anyones book) can go away.
	This also frees up a file type field for inodes for reuse.

And that's just what I can think of off the top of my head.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504191741.AA19086>