On Thu, 7 Feb 2002, Matthew Dharm wrote:
> On Wed, Feb 06, 2002 at 11:39:00PM +0100, G�rard Roudier wrote:
> > On Thu, 7 Feb 2002, Martin Wilck wrote:
> > > Just for curiosity about SCSI-4: If a SCSI-4 device answers an INQUIRY
> > > (even with only 36 bytes), won't it identify itself as a SCSI-4 device,
> > > thereby showing the driver that it should request more INQUIRY data?
> >
> > I already replied about this point.
>
> Hrm... I apparently missed this reply. At least, in my readings of your
> messages, I don't see you addressing this point with anything other than
> "all other probing mechanisms do it in a single command". Could you please
> elaborate on your position?
My position was not no castrate the currently unique INQUIRY command
performed by Linux SCSI to 36 bytes.
"All other probing processes using a single INQUIRY" is what I seem to
see.
> > > (Actually, it seems that Windows does 36byte INQUIRYs all the time.
> > > To work with Windows, a SCSI-4 device must operate that way).
> >
> > If we just want free O/Ses to work as well or not better that Windows,
> > then there is no interest in developing them in my opinion.
>
> Of course I want free OSes to work as well as possible. Right now, in this
> particular area, Linux works _worse_ than Windows. Clearly, that's
> unacceptable.
That's a philosophical issue.
Encouraging broken pieces of hardware not to be fixed is not working
better in my opinion. This looks like an attempt to cope with shit but
certainly not to clean it.
At least, we should not _silently_ band-aid our software and claim that
it was broken when it was not. You can count on me for making appropriate
noise in such situations. :-)
> And my comment about windows behavior (and I beleve Martin's also) are
> meant to point out that (a) this mechanism must work anyway, because (b)
> vendors are more often testing against the windows drivers rather than the
> published specification. We see this all the time -- hardware vendors
> don't really care about the full spec -- they only want to work with
> windows, and maybe MacOS. The fastest way to bring compatibility with a
> broad range of devices to Linux is to try to stay within the commonly-used
> code paths on device firmware.
Common does not mean the right thing to do in all situations. With such
philosophy, we still were living in caverns. :-)
G�rard.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
