Date: Tue, 27 Feb 2007 10:48:28 -0700 From: Scott Long <scottl@samsco.org> To: Warner Losh <imp@bsdimp.com> Cc: scsi@freebsd.org Subject: Re: Quirk for this? Message-ID: <45E46EEC.2010907@samsco.org> In-Reply-To: <20070227.104136.112559861.imp@bsdimp.com> References: <45E3092A.5040404@samsco.org> <7579f7fb0702261041ld6f4a09q732bbbc419cf1c73@mail.gmail.com> <45E444C6.40607@samsco.org> <20070227.104136.112559861.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote: >> I understand what you're saying. If you look in the umass driver, there >> is already a mechanism for quirks as well as a fairly large collection >> of quirks for bad SCSI protocol behavior from devices. These should all >> move up to CAM, I agree. However, what exists in CAM right now for >> XPORT-specific support is just a series of 'if' statements scattered >> around cam_xpt.c. If you moved Warner's quirk up as well as the other >> umass quirks, you're going to quickly make a royal mess out of >> cam_xpt.c. That's what I want to avoid. Once we figure out exactly >> what we want out of the XPORT code and get it a little more defined and >> organized, I think we can then start moving the quirks out of the umass >> driver. Until then, solving Warner's problem via umass.c is easy and >> doesn't complicate the end goal much at all. > > I would think that the quriks in the umass driver would be > communicated in a transport neutral way to cam_xpt.c and friends. ANY > transport could set ANY quirk and the code would just cope. No need > for the xpt layer to peer into the transport at all (or is that the > 'sim' in CAMese). > This is what I had in mind. Where the quirks come from is fairly arbitrary, but the code to execute the quirks will someday live in the XPT or periph drivers, not the SIM. > For the moment, hacking umass is easiest and when the more generic > mechanism comes along, the minor hack that I'm putting in wouldn't be > burdonsome. Yes, and consistent with how it's done now. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45E46EEC.2010907>