On Mon, 2 Oct 2017 16:11:04 +0200 Stanislav Brabec <sbrabec@xxxxxxx> wrote: > Michal Suchánek wrote: > > On Mon, 2 Oct 2017 15:06:33 +0200 > > Stanislav Brabec <sbrabec@xxxxxxx> wrote: > > > >> Michal Suchánek wrote: > >>> it is completely reasonable to return ENOMEDIUM from kernel when > >>> the tray is open and let userspace decide if it wants to attempt > >>> to close the tray and how long it wants to wait for the tray to > >>> close (it may be blocked/broken). > >>> > >> But then, what is the purpose of /proc/sys/dev/cdrom/autoclose? > > > > It can be used as a hint in mount if closing the tray is desired or > > not. > > Such feature could be completely implemented in the user space, so > there is no reason to stay in the kernel in such a limited form. > > 20 years ago, it was a completely working implementation inside the > kernel. User space just called mount(), and it succeeded. Ok, if you can point on a particular kernel version and driver that worked it might be interesting to see the implementation. > > If that requires user space loop loop, then there is no reason to > implement sysfs entry just to perform tray close inside mount() > syscall and then fail anyway. > As things are the kernel calls the tray_move function to close the tray. This function exits before the tray closes. The kernel proceeds to try to read the medium. There is a wait loop in ioctl calls (but not block calls) to check for ASC/ASCQ 04/01 (unit becoming ready). However, my cdrom reports 3A/02 (no medium, tray open) while the tray is closing. There is no code for 'tray closing'. Hence the open() call is not aware that the tray is supposed to close shortly and does not wait for it. Tracking the 'closing' state in the kernel does not look pretty. Best kernel-side option would be to wait for some arbitrary time in the tray_move function until the drive state changes from 'tray open'. I suspect waiting for arbitrary time or indefinitely until the tray closes may upset people. Then again, this is CD drive so it is anything but fast (unless emulated ;-) Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
