At Tue, 3 Feb 2015 13:39:06 +0000, One Thousand Gnomes wrote: > > > > It is no workaround, it's the SCSI spec. You only see events if you > > > lock the door. > > > > Yeah, I do understand the reason behind it. But: why udev has to take > > care of SCSI implementation details at this place at all? Isn't the > > place for the generic cdrom device? If it's only for obtaining the > > eject events, you're essentially working around the problem. Instead, > > the kernel should have provided a saner way to enable the event > > generation, IMO. > > You could take that to the SCSI and ATA committee's and then try and get > them to agree and every vendor on the planet to make every crapware USB > device implement it. Good luck. > > The kernel can provide only the lowest common denominator of service if > it provides a single unified model. In CD space thats a *very low common > denominator*
I meant the saner way ioctl implementation, not about something about the new hardware control. Currently, the media lock ioctl is used as a way to enable the event. So we can't handle the additional media lock properly since the state is a bool in kernel. If it's a flag with two bits (one for the media lock and one for the event enablement), user-space doesn't need to track the state by itself, for example. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
