From owner-freebsd-hackers Wed Apr 19 11:07:36 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA25105 for hackers-outgoing; Wed, 19 Apr 1995 11:07:36 -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 LAA25099 for ; Wed, 19 Apr 1995 11:07:35 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA19187; Wed, 19 Apr 95 12:00:42 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504191800.AA19187@cs.weber.edu> Subject: Re: [DEVFS] your opinions sought! To: simonm@dcs.gla.ac.uk (Dougal) Date: Wed, 19 Apr 95 12:00:41 MDT Cc: hackers@freefall.cdrom.com In-Reply-To: <199504191528.IAA22087@freefall.cdrom.com> from "Dougal" at Apr 19, 95 03:28:00 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > You know, I thought the major advantage of having a /dev directory is > that the kernel doesn't have to know the names of all the various > devices, because this mapping is specified by the filesystem. The > devfs is about to hardwire all this stuff in, at the expense of some > kernel bloat. Not true. It is a device-install-time wiring that occurs; the only think that will be wired is the relationship between node names and actual devices. This is erroneously missing from the /dev implementation. Please see my previous post on the merits of a devfs. I list at least 8 salient points in favor. > 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. Trade the kernel bloat of devfs for the bloat removal of killing specfs. > I hope this doesn't mean that some future things will actually > *require* the devfs, please keep it optional. I think remote boot and expanding minor numbers used as bit selectors *require* a devfs to support remote boot from older (ie: Sun) machines. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.