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
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
