On Wed, 21 Jun 2006, Andreas Mohr wrote: [...] > 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... The sg part should be implemented by each SCSI device, reducing the current sg device to a mostly empty shell. Then you can prevent that empty shell from binding to devices having more specific drivers. -- Top 100 things you don't want the sysadmin to say: 30. And what does it mean 'rm: .o: No such file or directory'? 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
