*BSD News Article 1772


Return to BSD News archive

Xref: sserve comp.unix.bsd:1805 comp.unix.internals:4895
Path: sserve!manuel!munnari.oz.au!mips!mips!sdd.hp.com!uakari.primate.wisc.edu!ames!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.bsd,comp.unix.internals
Subject: Re: Writing a device driver for CDROM
Keywords: bsd devicedriver cdrom
Message-ID: <24289@dog.ee.lbl.gov>
Date: 1 Jul 92 15:20:49 GMT
References: <1992Jun20.152106.159@rai.juice.or.jp>
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 69
NNTP-Posting-Host: 128.3.112.15

In article <1992Jun20.152106.159@rai.juice.or.jp> tetsuji@rai.juice.or.jp
(Tetsuji Rai) writes:
>  I'm trying to write a device driver for a CDROM drive ...
>     My question is very fundamental; when the "match" routine and the 
>"attach" routine should be called.

(The BSDI scsi configuration code is based on some of my work at LBL,
so I can answer this question.  The LBL stuff is in turn pretty much
what I described at a UKUUG some time ago.  [I forget which one; my
proceedingses are all at my office.])

>The scsi source files coming with BSD/386 are for hard disks and tape
>drives; ie non-removable devices, so "match" and "attach" routine (sdmatch
>and sdattach, internally) are called upon booting.  As for CDROM, the
>device is often changed, so I assume sdattach should be called each time
>it is mounted.

No: match and attach are used to find hardware.  The CDROM *drive* is
not physically removed from the bus; only the media are removable.
(Well, it is possible to move hardware with live power, but be *sure*
you know what you are doing.)

The autoconfiguration scheme boils down to the following:

	If I find a SCSI host adapter, I must find all the live
	targets (disk/tape/... controllers).  As I find each one,
	I call config_found() to announce the fact.

	config_found searches a configuration table.  For every
	possible match, it calls the driver's match function asking how
	close a match the configured device is to the actual device
	found.  (This match number is just an integer, with bigger
	numbers being ``better'' matches.  The idea here is to allow,
	e.g., a special exabyte tape driver to override a generic SCSI
	tape driver.  This lets you deal with broken hardware without
	embedding special-purpose #ifdef's in generic code.)

	Once config_found has found the best match, it calls the
	associated driver's attach function to tell it ``you have
	been found''.  In this case, the device just found is a
	SCSI target.  The target's attach function is to find all
	the live SCSI units (disk/tape/... drives).  As it finds
	each one, it must call config_found() to announce this.

The match and attach functions are entirely driver-dependent.  SCSI
disk, tape, CDROM, ... drivers should try to be machine-independent
(MI), and use only MI concepts such as ``unit number'' and ``logical
block''.  SCSI unit drivers are given access to machine-dependent host
bus adapter functions through upcall vectors in the ``hba_softc'' and
``hba_driver'' of the unit's target's parent (the hba).  Note that the
target level of this hierarchy is short-circuited in the common case of
a single unit on a target---this is the reason for the funny SCSI
queues---but is still present in the configuration.

Despite the sub-LUN stuff in the SCSI standards, I have never seen any
SCSI units that in turn drive sub-units.  Nonetheless, this particular
scheme should handle them.

The interface between a CDROM ``disk'' driver and the rest of the
system is up to you, but once matched and attached, the device entry is
there to stay.  (Currently, the configuration code allows devices to
appear `magically' on a bus iff the bus driver code notices and calls
config_found---that is, config_found is intended to be usable at any
time---but there is no support for ``unfinding'' a device.  This would
be easy now, but would complicate dynamic driver loading, if anyone
were to implement that.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov