Date: Tue, 26 Mar 1996 09:35:33 -0800 (PST) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: hdalog@zipnet.net Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@freebsd.org Subject: Re: HP 4020i CD-R wishes Message-ID: <199603261735.JAA06846@GndRsh.aac.dev.com> In-Reply-To: <199603261258.HAA03628@hda.com> from Peter Dufault at "Mar 26, 96 07:58:06 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > As JULIAN Elischer wrote: > > > It is becoming clear that we need to be able to 'stack' SCSI drivers. > > > I have three cases of this now... > > > > > > 1/WORM/CDROM > > > 2/TAPE/CHANGER > > > and the last.. more amazingly.. > > > 3/WORM/CDROM/CHANGER > > > > > > how can one identify such a situation, and which 'done' routine get's called? > > > > I think we need some layering scenario like for ioctl commands on > > ttys. They are being passed through the general ioctl code first, > > then to the line discipline, then down to the physical driver. > > (Something like this -- i didn't code-review it now.) > > We have some layering now, where you go through per-device ioctl > code first and then hit the general code if it wasn't handled. It > would probably benefit from one more layer: > > Specific device (specific WORM for example); Type device (WORM > class) General device (set debugging, etc). > > In terms of stacking - how about "This is a WORM and a CDROM and > a CHANGER", and you have to potentially open three devices to > exercise all three "personalities". Then which done to call is > clear. We have to pay attention to locking issues. Sounds good. Locking should occur as a scsibus/target/lun tuplet lock, so that the locks are independent of what kind of device it is being used as. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603261735.JAA06846>