Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: new new scsi release beta2 part 1 of 5 (fixed)SKIP
Message-ID: <1992Sep29.231322.19770@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Reply-To: terry@icarus.weber.edu
Organization: Weber State University (Ogden, UT)
References: <1992Sep23.221352.16254@tfs.com> <1992Sep28.130134.36@vtrm01.uucp> <1992Sep29.000351.8023@tfs.com>
Date: Tue, 29 Sep 92 23:13:22 GMT
Lines: 82
In article <1992Sep29.000351.8023@tfs.com> julian@tfs.com (Julian Elischer) writes:
>In article <1992Sep28.130134.36@vtrm01.uucp> dcope@vtrm01.uucp writes:
>>The problem with the supplied MAKEDEV file is it creates a major number of
>>(14). This is also the number of the printer. Did you ever try to print
>>to the tape drive.. does'nt work so well.
>
>Well I might say that the problem is that the lpt driver took my table entry.
>If you installed the patch to conf.c, then I guess you'll find the lpt driver
>on major number 15 or 16 (depending on which version you've installed)
>as MY patch will have inserted the entries for sd,st and cd in
>locations 13,14,15 of the cdevsw table.
>(so lpt will be device 16), (sorry)
>
>We have two different developers both independently
>claiming the "next free slot" in the cdevsw table.
>We need to get a central place where the numbers can be assigned.
>be warned however, I already have another device driver
>(for a scsi tape changer robot mechanism) so The next patch
>kit for scsi will push your lpt to location 17.
>
>take a look at i386/i386/conf.c
What we really need is some way of encapsulating the device name as part of
the entry. MAKEDEV should be part of kernel installation, and should
scan the symbol table and read the cdevsw and bdevsw entries. That
way, we can automatically generate devices from the current kernel
configuration rather than assigning entries at all.
The only potential for conflict is in naming and the only potential
problem is in assignment of minor device numbers and naming conventions
for devices with multiple minor entries (tty00, tty01, etc...).
It's possible that we should have the kernel itself redo device
creation on boot, based on the contents of the devswitch tables.
This would require the addition of a single field to the table.
By stopping table traversal at a 0 entry for the first character (device names
in the table would be limited to 'n' characters), we could also have an
easy meachnism for soft termination of the list of devices. This would
allow us to put several "empty" entries in the table for future allocation
by loadable devices.
At the very worst, the MAKEDEV would access a symbol-lookup-tool to get
the major and minor numbers based on a device name argument (or just
the major ones). A -1 major would be returned for "unconfigured" devices.
This would allow minor device numbers to be handled/fabricated on a per
device basis.
I also suggest that, if this is the route we follow, a /dev/MAKEDEV really
ought to call /dev/MAKEDEV.wd /sev/MAKEDEV.tty (actually, /dev/MAKEDEV.*)
making only those device that don't have -1 as a return.
Thus we need not modify the MAKEDEV for each device we add; instead, we simply
drop in a new MAKEDEV module. This is similar in scope to SCO's method,
which uses the directory /usr/lib/mkdev/ to hold the per device production/
configuration scripts.
Currently, the command line configuration tools are abominable. I shouldn't
have to edit my file (hoping I have the right one) to change an IRQ or add
pty's, config it, change directories (making sure I get the one named the
same as my file), make depend, make, and then manually install the resulting
executable, remembering to delete the devices which are no longer applicable
to my new configuration, and adding the ones which are but did not exist
prior to the most recent rebuild.
Opinions?
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
terry_lambert@npd.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
-------------------------------------------------------------------------------