From owner-freebsd-hardware  Wed Apr 19 11:02:41 1995
Return-Path: hardware-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id LAA24984
          for hardware-outgoing; Wed, 19 Apr 1995 11:02:41 -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 LAA24978
          ; Wed, 19 Apr 1995 11:02:37 -0700
Received: by cs.weber.edu (4.1/SMI-4.1.1)
	id AA19153; Wed, 19 Apr 95 11:54:59 MDT
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9504191754.AA19153@cs.weber.edu>
Subject: Re: [DEVFS] your opinions sought!
To: peter@bonkers.taronga.com (Peter da Silva)
Date: Wed, 19 Apr 95 11:54:59 MDT
Cc: julian@freefall.cdrom.com, fs@freefall.cdrom.com,
        hackers@freefall.cdrom.com, hardware@freefall.cdrom.com
In-Reply-To: <199504191240.HAA14829@bonkers.taronga.com> from "Peter da Silva" at Apr 19, 95 07:40:06 am
X-Mailer: ELM [version 2.4dev PL52]
Sender: hardware-owner@FreeBSD.org
Precedence: bulk

> I don't see any reason in devfs to make these symlinks, since it's all
> virtual anyway... just have them both have the same major/minor. 

The reason for symlinks is to cannonize the access to the devices
by heirarchy.  This means that the same heirarchy is used for each
access.  The point in doing this is to embed some of the device
information in the heirarchy itself.  Typically, this would be what
was formerly called the minor device number.

> Secondly, is there a technical reason for separating wdn from sdn in the
> disk-only view?

I see a reason for seperation by controller instance, but not by
controller type.  The main issue in controller type is instance order
to the BIOS to determine which disk we are booting from when we are
booting from 0x83.  I think this is totally irrelevant to the
discussion of device creation.

On the other hand, one could certainly desire to have direct access to
the SCSI bus on a per target basis... although perhaps the same is
true of EIDE.

> Finally, since you only show things that actually exist, there's not much
> point to a deep hierarchy. Sun's devfs uses a hierarchy and it's a pain...

Again, it's useful to unclutter the top level directory AND to add a
major number while still getting rid of specfs entirely.

> A little hierarchy to avoid /dev chaos with everything in one place, yes,
> but how about just two levels?

I agree.  You *can't* exceed two levels within the representational
geometry anyway, since the only thing you are passed to resolve a
path component is the directory vnode pointer of the previous path
component and the path component to resolve.  You can assume you are
on /dev easily enough, which gives you a single selector.  The only
way around this would be adding an argument to the lookup that was a
pointer to a long that could be modified by the called FS to generate
context for looking up subsequent path components.  Direct use of
the context as a synthetic inode value (you could not use it for a
vnode, since by then that vnode has been unlocked) yields only a
single additional lookup depth.  Anything beyond that would require
that the long be used as a pointer to a file system specific context
record.  As I said in a previous post, I have every intention os
using this mechanism some day anyway.

[ ... blue sky ... ]

I agree with most of this, but would suggest two digit naming to ensure
place holders and to simplify the per device name generation.  This
admittedly results in a loss of 10 potential devices, but I think a
distinction between a '07' and a '7' device would be confusing in and
of itself anyway.


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