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