Re: Can't eject a previously mounted CD?

[Walt H <waltabbyh@comcast.net>]

Ed Sweetman wrote:
> In your patch here i think the person who made the code originally
> confused or got wrong the conditions of success for opening the cdrom
> drive. This is in the same function as the patch applies to.
> 
>        if ((fp->f_flags & O_NONBLOCK) && (cdi->options & CDO_USE_FFLAGS))
>                 ret = cdi->ops->open(cdi, 1);
>         else
>                 ret = open_for_data(cdi);
> 
> 
>         if (!ret) cdi->use_count++;

Doesn't this increment it if the call succeeds? In open_for_data, ret is the
return code from the open call, which should be zero upon success. Problem is,
we already incremented it when we entered cdrom_open.

> 
> Here we see that if the open fails we incriment our use_count.  But this
> doesn't make sense. We increment the use_count at the  beginning of the
> function as a "lock" so that we can't do anything while the open
> function is executing like rmmod the cdrom (supposedly?).  Now removing
> the if(!ret) line makes sense. Under the out: label, if the open fails,
> then we close our makeshift lock on the device because our function is
> done. If it succeeded, then the use_count stays at 1 we go along our
> merry way.
> 

Yeah, my patch is just a hack :)  Not really for general use i think, but it
allows me to open the door using the button. The cdrom.c from test11-mm1 never
incremented use_count until after the success of one of the preceeding calls. I
was just undoing the original increment that now happens upon entering
cdrom_open. The use_count does control the door lock though. If you look under
cdrom_release, the door unlock code never gets executed until use_count=0. I
haven't checked overall operation of my cdrom drives enough to know what else is
wrong.

-Walt