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: Some ideas on the driver interface (New idea!)
Message-ID: <1993Mar17.210727.5890@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1nj0ej$j6s@walt.ee.pdx.edu> <C3p9M9.72J@sugar.neosoft.com> <1993Mar17.122612.5929@neptune.inf.ethz.ch>
Date: Wed, 17 Mar 93 21:07:27 GMT
Lines: 67
Sorry for not obeying the "followup to poster" -- maybe if it pointed to
Peter's list?
In article <1993Mar17.122612.5929@neptune.inf.ethz.ch> weingart@inf.ethz.ch writes:
>How about something like this:
>
>cat /etc/fstab:
>
>#
># First mount real disks
>#
>sd2a / 4.2 rw 1 1
>sd2d /usr 4.2 rw 1 2
>sd3e /home 4.2 rw 1 3
>#
># The rest are 'pseudo' disks
>#
>swap /tmp tmp rw 0 0
>dev /dev dev rw 0 0
>proc /proc proc rw 0 0
>
>
>
>There. Simple no? Instead of making mount(2) take a special file,
>make it take a string representing the device. The "dev" device would
>be mounted on /dev, and emulate like it was a real /dev. This way
>only the devices that were configured into the kernel would even
>need to show up in "dev".
>
>Would be a neat way to dynamically allocate more ptys for example.
>the "dev" driver/stuff-in-kernel would simply have to simulate like
>there are more of them all of a sudden.
This is a lot cleaner than some of the other suggestions (like the ones
I made) at dealing with the issue of root mount and of mounting file
systems without a /dev directory present; HOWEVER, there are still a
number of critical issues dealing with boot which have to be dealt with,
in particular the remount of root during boot to install.
This still does not cover the issue of user supplied device aliases,
nor does it cover the issues of devices in directories other than /dev
(unless we demand symlinks instead) or the generation of devices whose
minor numbers are divided into bitfields with special significance,
like /dev/cua0 being /dev/tty0 with bit 128 set in the minor, or the
no rewind/no retension/low density tape devices.
I think the dynamic allocation of pty's requires we go to a clone device
paradigm anyway, since we can't infinitely expand the name space on the
pseudo-partition "/dev".
Typically, clone devices inodes are created in /tmp, not /dev. To deviate
significantly from this will mean a rewrite of nearly all streams drivers
ported to 386BSD (assuming we will eventually support streams). I would
prefer to avoid breaking this if at all possible.
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
-------------------------------------------------------------------------------