Re: [regression] CD-DA delay needed after insertion (http://bugzilla.kernel.org/show_bug.cgi?id=10974)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> It happens on anything after 2.6.24 (cfr.
> http://bugzilla.kernel.org/show_bug.cgi?id=10974).
> E.g. mainline 2.6.27-rc8.

Ah.

Geert, I'm sorry this has come up and thanks for bringing it to my attention.

I'm relying on 15 year old behavior.  It has always been the case that
the packet pass-through interfaces treat O_NONBLOCK as 'don't wait for
commands' (ie, classic async communication or, in the case of SGIO,
don't block on mandatory locks) not 'change how you mediate the
communication'.  The whole point of the passthrough interface is
'please don't fuck with the packet stream.  My userspace application
knows better than the kernel in this case'.  If the kernel has
suddenly changed that, it is responsible for the loss of
functionality, not cdparanoia.

It is also the case that the kernel randomly interspersing its own
packets, commands and setup would be yanking setup state out from
under cdparanoia.  What am I supposed to do if I set density and
completely change the data mode of a cdrom drive (persistent across
disc changes), or change the block descriptor caching extents, only to
have the kernel decide to change them back without warning? If you
eject media with one of these new kernels, do I still get any
meaningful sense state, or is the sense key and all subsequent
commands merely intercepted and refused?  What happens on a timeout?
A media error?  A bus reset?  Does any 'CHECK CONDITION' status
completely yank the rug out from under the passthrough?

The kernel must not interfere with the pass-through or cdparanoia is
castrated. Or... I'm back to the era of enacting workarounds based on
kernel dot-version.  Regardless, this is a change to a longstanding
behavior.  Is it on purpose, unintentional or 'intentional but without
realizing it was actually important'?  Would be interesting to know.

> In this case, sg means scatter/gather, and it's a purely internal
> interface.  It does not start/stop the drive, nor the scsi interface.

Ah, I confused it with a much older utility that would up/down an SG
device entirely.

Monty
--
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux