> On Mon, 7 Jun 1999, Mike Smith wrote: > > > > 12.A, 21.*, and 23.* are known to be buggy...13.A doesn't appear to be. > > > Since the current method of sorting out the revisions doesn't seem to > > > be perfect, would it be acceptible to consider them all buggy unless known > > > not to be (i.e. compare ap->revision instead of ap->model)? > > > > Uh, that's what the code does; if it's a Zip drive, it's considered to > > be buggy regardless of revision. If the string compare isn't matching > > a drive in the field, it means that Iomega have changed the string and > > we need to know what the new drives are calling themselves. > > > > I have an off-brand (NEC) Zip Drive with: > <IOMEGA ZIP 100 ATAPI Floppy/12.A> > which does have buggy firmware; I also have another one with: > <IOMEGA ZIP 100 ATAPI/13.A> > that has no problem when I remove the 64 block limitation. > > In this case, I would use strncmp instead of strcmp to test the first 27 > characters.
Gotcha, and that's definitely a good idea. > So what you are saying is that we are limiting all Zip drives instead of > being based solely on firmware revision? Any reason for that? No evidence suggesting that any revision ever worked or would work; the simplest and safest technique is just to cap transfers at 32k - in reality it doesn't affect performance at all, so there's no real need to be extra-picky. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\ -- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
