http://qa.mandrakesoft.com/show_bug.cgi?id=5692
Product: kernel
Component: default
Summary: CD cdrom door / tray won't open
Product: kernel
Version: 2.4.22-8mdk
Platform: PC
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: default
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
This is probably more of a design issue than a bug but I want to hear the
reasons for, and encourage a re-thinking of, the current design.
It was really silly for CD drive manufacturers to add a software disable for the
eject button on the front of a READ-ONLY device. I blame them initially for all
this frustration/confusion, but we programmers could fix this problem if we
want. The general problem: more and more things that used to be simple about
computers are becoming complex. Enter this particular example: often the cdrom
won't give you the disk and there is usually "no good reason" for it to refuse.
I'm an OS programmer. I know handling I/O faults is a pain and have often
wanted to ignore the error paths and events that abort device reads (especially
the async reads). But locking the drive door for a read-only device just
because we can is a really bad idea. This makes for an UNresponsive machine
that does not act the way it is expected and ultimately creates distrust in the
user about his system and our software. I should NOT have to type 'eject' to
make the drive open. (This is not a MAC, there IS a button, so it needs to work
whenever possible) The errors must be handled anyway so the OS and all the apps
that use the device must always be prepared for "media is gone". I don't care
if the device is mounted or even in the middle of a read, when I push the open
door button I expect to hear the device spin down immediately and open the door
- no questions asked. The kernel and apps should recover from these errors
gracefully - it should really be no big deal.
I strongly encourage a rethinking of this design. Fight the urge to lock
removable media drives unless *and only while* they are writing. We want
machines that are responsive. Beeping the PC speaker would be a good way to say
the software knows the user pressed the open door button while the device is
writing (but there probably isn't hardware support for this). An attitude like
this will greatly improve the "look and feel" of the user's machine and our
software.
Copy this to any application writers that need to get involved.
Next time I'll go after the Power Button... (but not on a software forum :)
--
Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
