From owner-freebsd-hardware  Wed Apr 19 10:22:54 1995
Return-Path: hardware-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id KAA24287
          for hardware-outgoing; Wed, 19 Apr 1995 10:22:54 -0700
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA24280
          ; Wed, 19 Apr 1995 10:22:50 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
	id AA18992; Wed, 19 Apr 95 11:16:27 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9504191716.AA18992@cs.weber.edu>
Subject: Re: [DEVFS] your opinions sought!
To: julian@freefall.cdrom.com (Julian Elischer)
Date: Wed, 19 Apr 95 11:16:27 MDT
Cc: fs@freefall.cdrom.com, hackers@freefall.cdrom.com,
        hardware@freefall.cdrom.com
In-Reply-To: <199504190519.WAA06359@freefall.cdrom.com> from "Julian Elischer" at Apr 18, 95 10:19:33 pm
X-Mailer: ELM [version 2.4dev PL52]
Sender: hardware-owner@FreeBSD.org
Precedence: bulk

> I am about ready to let people hack at devfs.
> but one thing I'm not sure about:
> 
> what is a good way for the devfs to appear?

/dev/dsk/...		block disk
/dev/rdsk/...		raw disk
/dev/tty/...		tty device
/dev/ttym/...		modem control tty device
/dev/ptm/...		master pty
/dev/pts/...		slave pty
/dev/con/...		console (keyboard, mouse, display, sound)
/dev/mem
/dev/kmem
/dev/null
/dev/zero
/dev/tty

I'd suggest that there needs to be heirarchy at least to this point.

Then there are compatability issues:

/dev/icmp
/dev/tcp
/dev/udp
/dev/spx
/dev/ip
/dev/ipx
/dev/socksys
/dev/fd096ds15
etc.

These probably ought to be installed when the support modules for them
are installed (either statically or dynmaically).  For instance, the
majority of the items in the immediately previous list are for IBCS2
support.  The compatability devices that duplicate functionality
(like /dev/fd096ds15) should be symbolic links to the "real" device.

The ... entries should be handled on a case by case basis.  Note that
the heircy itself implies an additional selection mechanism that would
have normally be handled by major # + minor # bits.  The use of symbolic
rather than hard links preserves this.  Unless we want to change the
lookup mechanism to include flags that can be modified by previous
path component lookup mechanisms when it goes iterative, this limits
the available heirarchy depth to 1 directory deep.

As an aside, I *would* like to add the lookup recursion flags at some
point to allow easy support of multiple name spaces for a single file
(ie: DOS, MAC, OS/2, and UNIX names for each file) using the POSIX
"//" escape mechanism, which can only be effective on subcomponents
as a file system selector currently, and should be usable as a flag).

I would suggest a secondary heirarchy on the disks of DOS partition;
this should be an optional layer for non-DOS-aware platforms; this
perhaps implies a seperate set of nodes for the floppy device, since
on DOS boxes, the floppy does not have DOS partition tables.

The console device as a seperate heirarchy is a nice abstraction.  This
is because it allows you to change directory ownership overall on login
and the permissions on devices associated with the console "just change".

It is likely that we will want symlinks from the /dev/tty directory into
the console directory to unify the console/non-console name space.  At
this point, the two letter reporting limit is now a problem.  It is
likely that we will want a symlink for any device that does cannonical
processing using the termios code into the tty directory.  I suggest
the following for a start:

new			old
-----------------	-----------------
/dev/tty/00		/dev/tty00
/dev/tty/c0		/dev/cons0

etc.


That's my first take on it anyway...


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