Date: Mon, 26 Feb 2007 13:04:23 -0800 From: "Matthew Jacob" <lydianconcepts@gmail.com> To: "Warner Losh" <imp@bsdimp.com> Cc: scsi@freebsd.org Subject: Re: Quirk for this? Message-ID: <7579f7fb0702261304yd52d46dy81e3ac30e02807b5@mail.gmail.com> In-Reply-To: <20070226.133739.74686216.imp@bsdimp.com> References: <7579f7fb0702252331m7d3a61c5u224d898b4f04248c@mail.gmail.com> <45E3092A.5040404@samsco.org> <7579f7fb0702261041ld6f4a09q732bbbc419cf1c73@mail.gmail.com> <20070226.133739.74686216.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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. On 2/26/07, Warner Losh <imp@bsdimp.com> wrote: > > It may be a property specific to USB devices, but the code affected is > > a property of the end target at the end of a transport, not the > > transport itself. > > The transport already does so much futzing with the scsi > request/replies that go down to the device that one more wouldn't be > so horrible and would confine this brain-damage to the devices that > have it... > > Warner >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7579f7fb0702261304yd52d46dy81e3ac30e02807b5>