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!gatech!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: <1993Mar19.181458.29502@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1993Mar17.122612.5929@neptune.inf.ethz.ch> <1993Mar17.210727.5890@fcom.cc.utah.edu> <1993Mar18.233944.10349@uvm.edu>
Date: Fri, 19 Mar 93 18:14:58 GMT
Lines: 87
In article <1993Mar18.233944.10349@uvm.edu> wollman@sadye.emba.uvm.edu (Garrett Wollman) writes:
>In article <1993Mar17.210727.5890@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>
>>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.
>
>Well, I was thinking (to go along with my model of dynamic kernel
>module loading) that the device driver itself would be responsible for
>creating all the devfs entries... So, you'd have something like:
>
> dev_t slot = makedev(-1,-1);
> if(cdev_register(&info, &slot)) do something;
> if(devfs_cregister("tty", slot, 0, NTTY, 0)) cleanup;
> if(devfs_cregister("cua", slot, 0, NTTY, 128)) cleanup;
>
>or
> if(bdev_register(&info, &slot)) get out;
> for(i=0; i < NWD; i++)
> if(devfs_bcregister("wd", slot, 16*i, 15, 0)) cleanup;
This is fine for loadable device; are you suggesting the same for all
devices? It could only be a partial soloution in that case (unless we
agreed that *all* devices be loaded); specifically, what could be done
about SCSI devices? Target recognition and device classification based
on probe results certainly won't "do the right thing" for older tape
drives, among other things.
The new AHA1542C has passive termination, meaning I can have 3 machines
on the same SCSI cable, alternately acting as master or slave devices.
Identifying one of these and creating the "correct" device file for it
is certain to be a three toed bitch.
>>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".
>
>Just do it like AIX 3 does (only get it right).
>
> devfs_mpxregister("ptc", slot, 0, &ptc_nextfree);
> devfs_mpxregister("pts", slot, 0, &pts_nextfree);
>
>Would create entries in the devfs that look like AIX's /dev/pts and
>/dev/ptc; accessing `/dev/ptc' directly is treated as an access to
>`/dev/ptc/<nextfree>', where <nextfree> is passed in like above.
>Access to `/dev/pt?/NUMBER' is translated into minor device NUMBER,
>just like you'd expect.
The promotion of the directory inode to a device inode implies a bit of
awfully wierd code in the fs; for instance, how can one tell the difference
between an open of '/dev/ptc' by a process desiring a pty and a process
desiring a listing of directory contents? This implies that there is some
maintenance of state between the open and the first operation on the device,
with the first operation being VOP_READDIR() (a result of getdents() from
the "readdir" call in libc) causing the open instance to behave as a
directory. There is also the issue of lookup of terminal objects within
the device directory (which by definition requires the traversal of the
top level inode as a directory).
AIX deals with these issues using a kernel process, a luxury we do not have
available to us (yet).
The standard clone/control device pardigm is something we will have to
support for streams or streams-like systems in any case, and there is a
lot of code written that expects /tmp to be used for the device instances;
I don't see any real reason to change this, although I have to admit to
admiring some of the architectural decisions in AIX.
>Now if only I had the time to actually implement this...
Yep, I know *exactly* what you mean....
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
-------------------------------------------------------------------------------