[Danny, you do know I do not get cooker, do not you? :)] >> Also, >> when device is locked neither manual (eject button) nor program >> (eject /dev/cdrom) eject are possible. It does not work well for >> sd unfortunately. > what exactly does not work?
sd does not implement eject as atomic ioctl - instead "eject" is using three generic pass-through SCSI commands (unlock, eject and something else, I forgot). It means that - only root is allowed to use these ioctls (and rightfully so) - you can't actually check usage count because these ioctls appear unrelated to each other. I plan to add support fot CDEJECT (or similar) to sd and make eject program to try next method only if previous one returned ENOSYS. It won't fix it for all cases but will for most common usage. >> >> (It is possible to lock device only on rw operations. Suggestions >> are welcome). > why not? because I do not want to make it default and it makes code messy if done conditionally. If there is enough demand ... > I would like to add something more ambitious. So shoot me down if > you think that this proposal is _not_ what supermount should be > doing. I won't shoot you but it is _not_ what supermount should be doing. > I'd like to see a transparent way of access to audio cds (and vcd > and the like). There is something already doing this called cdfs > IIRC, haven't looked at it for some time. But currently GUI apps > try to do this kinda thing by implementing things like audiocd:// > io_slaves and the like. A very silly solution, why doesn't the > kernel handle this? Possible reasons: 1. because nobody was motivated enough to do it 2. because it is easily done using user-level tools so adding this to kernel just bloats it without any obvious advantage > As I said, perhaps it is better to improve cdfs and let supermount > use this as subfs (if possible). It is possible as long as cdfs is VFS API compliant. Supermount does not care about media as long as subfs reported it was mounted successfully. But any implementation must make it possible for cdfs/iso9660 to coexist (i.e. they must not return -ENOMEDIA when they see unknown format. That is what happens currently with iso9660 and that has to be changed). -andrey
