From owner-freebsd-hackers Wed Apr 19 11:06:52 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA25086 for hackers-outgoing; Wed, 19 Apr 1995 11:06:52 -0700 Received: from mpp.com (dialup-1-61.gw.umn.edu [134.84.101.61]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA25076 for ; Wed, 19 Apr 1995 11:06:48 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id NAA05091; Wed, 19 Apr 1995 13:02:54 -0500 From: Mike Pritchard Message-Id: <199504191802.NAA05091@mpp.com> Subject: Re: [DEVFS] your opinions sought! To: davidg@Root.COM Date: Wed, 19 Apr 1995 13:02:53 -0500 (CDT) Cc: bde@zeta.org.au, julian@ref.tfs.com, hackers@FreeBSD.org In-Reply-To: <199504191017.DAA00268@corbin.Root.COM> from "David Greenman" at Apr 19, 95 03:17:04 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1588 Sender: hackers-owner@FreeBSD.org Precedence: bulk > >>I personally have always prefered the flat scheme of /dev (with possible > >>exceptions for /dev/fd/*). This is a religious issue, I have spoken my > >>religion. > > > >I like it fairly flat. There certainly shouldn't be subdirectories for > >pieces of one device. > > I agree with Bruce. I would have agreed with Rod, but the simple fact is > that our /dev directory is getting very large and bloated, and this will only > get worse. Perhaps /dev/disks/* and /dev/ttys/*, etc, might be a way to > organize things (in other words, by device class). I prefer to not minimize > the number of levels as much as possible, while still providing some > organization. > > -DG I've used systems in the past that were setup like: /dev/rdsk/*, /dev/dsk/*, /dev/tty/*, /dev/pty/*, etc... Only a handfull of oddball devices were left in /dev. E.g /dev/null, console, mem, kmem, etc... My only problem with it was if I forgot which type of machine I was on and was looking for a /dev/xxx file instead of a /dev/rdsk/xxx file. >> it also means that disk slices can be shown only when they >> actually exist on the disk.. > > Well, it's perfectly feasible (and adds less kernel bloat) to query > the kernel at boot time for attached devices and build up the /dev > directory based on the information. This IMHO is a better solution > than the devfs. > > Simon I've also seen some system that was able to generate /dev by reading information out of the kernel at run time. -- Mike Pritchard pritc003@maroon.tc.umn.edu "Go that way. Really fast. If something gets in your way, turn"