Date: Mon, 7 Jun 1999 15:04:33 -0400 (EDT) From: "Chris D. Faulhaber" <jedgar@fxp.org> To: Mike Smith <mike@smith.net.au> Cc: Junichi Satoh <junichi@junichi.org>, hackers@freebsd.org Subject: Re: wfd.c and ATAPI Zip Message-ID: <Pine.BSF.4.10.9906071458370.15515-100000@pawn.primelocation.net> In-Reply-To: <199906071851.LAA00571@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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?
-----
Chris D. Faulhaber <jedgar@fxp.org> | All the true gurus I've met never
System/Network Administrator, | claimed they were one, and always
Reality Check Information, Inc. | pointed to someone better.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9906071458370.15515-100000>