Date: Mon, 26 Feb 2007 14:40:44 -0700 From: Scott Long <scottl@samsco.org> To: Matthew Jacob <lydianconcepts@gmail.com> Cc: Warner Losh <imp@bsdimp.com>, scsi@freebsd.org Subject: Re: Quirk for this? Message-ID: <45E353DC.10500@samsco.org> In-Reply-To: <7579f7fb0702261304yd52d46dy81e3ac30e02807b5@mail.gmail.com> References: <7579f7fb0702252331m7d3a61c5u224d898b4f04248c@mail.gmail.com> <45E3092A.5040404@samsco.org> <7579f7fb0702261041ld6f4a09q732bbbc419cf1c73@mail.gmail.com> <20070226.133739.74686216.imp@bsdimp.com> <7579f7fb0702261304yd52d46dy81e3ac30e02807b5@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote: > Oh, agreed. But rather than wander off into the umass code, thus > spreading quirks around hither and yon, would it make sense to just do > this in da which allows you to check transport type (now at least, for > CAM_NEWTRAN). > > And this means, btw, that I don't believe it's necessary to fix all > instantiations of READ CAPACITY (so that camcontrol(8) works). > If you do the processing in the umass driver then camcontrol still works. What I'm talking about, and I believe that Warner is agreeing with, is sniffing the completion of all CDB's to see which ones are READ_CAPACITY responses, and then fudging the data before calling xpt_done(). > > BTW- now that I think about it, I think that the 'taste' stuff that > GEOM does with disk devices (reading the last sector) actually > wouldn't work with tradtional MagnetoOptical devices anyway- you > cannot read unrecorded media in this case- so GEOM might have to be > dealt with at some point anyway. > It would require similar handling as the CD driver, where the capacity can essentially change during a burning session. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45E353DC.10500>