Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!wupost!bigboy.sbc.com!news.mtholyoke.edu!news.byu.edu!ns.novell.com!gateway.univel.com!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Driver Configuration
Message-ID: <1993Mar17.011127.14114@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <C3wwDx.7KA@csi.compuserve.com>
Date: Wed, 17 Mar 93 01:11:27 GMT
Lines: 50
In article <C3wwDx.7KA@csi.compuserve.com> proven@csi.compuserve.com (Chris Provenzano) writes:
>Well I've heard some interesting suggetions on the device configuration
>problem, and here is my assessment and solution.
[ ... ]
>From this the solution to me is obvious. Make a device filesystem.
>The kerner configuration files will have a name, uid, gid, mode, and type
>information in the conf file. Config will make a device table, and at boot
>time the device filesystem is mounted on /dev. There is no need for
>mknod anymore since all the devices will appear autommagically at mount.
There are several problems with the idea of a "non-translucent" device
file system that doesn't survive between reboots:
1) Linked device defaults, such as /dev/install, /dev/tap, /dev/floppy,
/dev/modem and other place-holder files are destroyed every shutdown,
as is anything else the user places in the /dev directory themselves.
2) Multi-homed devices (same major, different minor) require complex
specifications. Consider raw/non-raw, rewind/norewind, high density/
medium density/low density, modem control/non-modem control, and
tty/cua (open priority differentiated) devices all have to be
specified somewhere.
When considering a "translucent" file system, where the real device directory
is overlayed by the contents of the /dev directory off of root, you need to
figure (A) we don't support translucent file systems and (B) we don't support
the translucent mounting of / over the /dev pseudo file system. The idea
of a translucent file system also implies that links can not be used as
device locks (a stupid idea, but some software does it) and that symbolic
links will have to be used for linked defaults, which could interfere with
any future ability to provide a streams-style interface.
I have to vote against the idea of a device file system; however, having the
MAKEDEV script converted to a program so that it can "ask" the kernel what
devices are supported, and having built-in class rules combined with user
options for device building appeals to me, if only because it promotes
device creation from "manual" to "mostly automatic".
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------