cdcontrol purpose

[Andriy Gapon]

on 14/01/2008 23:40 Kris Kennaway said the following:
> Alfred Perlstein wrote:
>> * Andriy Gapon <avg at icyb.net.ua> [080114 09:18] wrote:
>>> on 14/01/2008 19:06 Alfred Perlstein said the following:
>>>> * Andriy Gapon <avg at icyb.net.ua> [080114 08:57] wrote:
>>>>> So I hope my question would be clearer now: should cdcontrol be allowed
>>>>> to override "prevent" issued by mount/open(2) and eject a disk in use ?
>>>>> Or should it simply fail in the same way that the physical button is
>>>>> disabled?
>>>> It should not.
>>> Sorry, I am not completely sure which question you answered with that,
>>> damn alternative questions :-)
>>>
>> Regarding: 
>>
>>>>> should cdcontrol be allowed
>>>>> to override "prevent" issued by mount/open(2) and eject a disk in use ?
>> It should not do this.  It should NOT eject a disk in use.
>>
>> Furthermore:
>>
>>>> If in that situation the tool does not emit a diagnostic that's
>>>> useful then it could be augmented to do so.
>>
>>
> 
> When I tried this last it indeed did not eject a mounted CDROM.  I 
> wonder if Andriy's hardware is not responding to the "lock media" 
> command or something.  Can anyone else confirm this behaviour?

Kris,

as I reported in this posting:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=457200+0+archive/2007/freebsd-stable/20071223.freebsd-stable

the behavior differs for SCSI and ATAPI devices, with the latter some
checks within the driver forbid 'eject' command, but do not forbid
'allow'. So, while you can not eject a disk with cdcontrol alone,
drive's tray becomes unlocked and now you can do it with a physical
button. This is even weirder behavior than what happens with SCSI.

-- 
Andriy Gapon