Hi,
On Wed, Jun 21, 2006 at 03:02:44PM -0400, Alan Stern wrote:
> On Wed, 21 Jun 2006, Andreas Mohr wrote:
>
> > Maybe it's better to (additionally?) go down the route of fixing up
> > low-level communication weaknesses (since it's been semi-confirmed that it's
> > an USB communication issue, see other thread part).
> > IMHO this is a severe user experience issue that shouldn't be fixed up
> > ("covered", "hidden") by the O_EXCL thingy alone.
>
> It's not a USB issue; it's a matter of lack of coordination between the sg
> and sr drivers. Each is unaware of the actions of the other, even when
> they are speaking to the same device.
Right, I could have expressed it much better before, sorry.
Found the relevant code:
sd.c sd_open()
if (!sdkp->openers++ && sdev->removable) {
if (scsi_block_when_processing_errors(sdev))
scsi_set_medium_removal(sdev, SCSI_REMOVAL_PREVENT);
}
And the obvious question would be whether the sdkp->openers++ thingy
could somehow be extended to enclose all hardware device users so that
e.g. sr.c wouldn't send ALLOW_MEDIUM_REMOVAL on a device already locked
by e.g. the sd.c driver.
Difficult question, though, since the group of drivers possible to use
with a certain device is not a static set:
it could be via
- sr.c
- sd.c
- IDE (in the case of ATA devices mapped via ide-scsi)
- ???
Is it possible to have such a per-*hardware*-device instance in the kernel
to keep track of various things such as number of device openers?
I'll do some investigation myself, too...
Thanks!
Andreas Mohr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
