On Sat, Jun 11, 2016 at 11:09 AM, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Two current fixes: one affects Qemu CD ROM emulation, which stopped
> working after the updates in SCSI to require VPD pages from all
> conformant devices. Fix temporarily by blacklisting Qemu (we can relax
> later when they come into compliance).
Is there some reason to believe that the qemu CD-ROM emulation is the
only one with this problem?
When some device is known to break because the SCSI layer made some
check stricter, why didn't you just relax the check again?
In other words, you already have one known device that behaves a way
that the new code doesn't like, why do you think the new code is
correct?
And don't answer "specs". Specs are just so much toilet paper.
If the Qemu CD-ROM emulation has worked with not just older versions
of Linux, but presumably Windows and other OS's too, then it's likely
that nobody has ever cared about the VPD pages before, and thus the
new code that requires VPD is likely to break other things too.
So give a reason why you think qemu is _sop_ special, and why the new
and clearly broken "require VPD" code is _so_ important.
And really, if the reason is "specs", then somebody needs to get their
head examined. We've had so many devices that only glance quickly at
the specs that people need to realize that paperwork is one thing, and
reality is another, and the two have only a very tenuous connection.
The commit that adds this "no VPD" entry doesn't even talk about when
we broke this. What change exactly was it that broke things?
I've pulled this, but I really think that this was completely bogus.
Even if blacklisting ends up being the right thing to do in the end,
the lack of explanations is awful, and the assumption that it's just
one particular device is very very suspect.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
