[sane-devel] SCSI problems with avision backend

[Douglas Gilbert]

Henning Meier-Geinitz wrote:
> Hi,
> 
> On Thu, Apr 11, 2002 at 11:58:21PM -0400, Douglas Gilbert wrote:
> 
>>If you open an sg device with O_EXCL and it is already open
>>then:
>>  - if O_NONBLOCK is also set then the open() will fail
>>    with EBUSY
>>  - otherwise you will wait (interruptible) until the existing
>>    open()s on that device are close()d.
>>
> 
> Ok, that sounds reasonable. I was just a bit surprissed because I
> thought we gor EBUSY until some time ago.
> 
> 
>>All scsi bus scans done using sg should use O_NONBLOCK else
>>they run the risk of hanging on somebody else's O_EXCL lock.
>>
> 
> So we would change sanei_scsi.c line 1113
> 
>   fd = open (dev, O_RDWR | O_EXCL);
>   
> to
> 
>   fd = open (dev, O_RDWR | O_EXCL | O_NONBLOCK);
> 
> ? 

Henning,
Yes, I think so. It is probably always a good idea to open() a
sg device O_NONBLOCK. Then if blocking semantics are required:
         int f = fcntl(fd, F_GETFL);
         fcntl(fd, F_SETFL, f & (~ O_NONBLOCK));

> Does this work with the other operating systems also. Or to be more
> exact, O_NONBLOCK compiles everywhere? The man page suggests that it's
> not Linux-specific.

That is a difficult one to answer. Device drivers tend to
interpret O_RDONLY, O_EXCL and O_NONBLOCK (etc) in a way
that is appropriate for those drivers and what is permitted
by the kernel architecture. The standards pin down those flags'
behaviour for normal files, pipes, etc.

It also gets a bit fuzzy depending on what level you wish
to look at things. For example: what does O_RDONLY mean to
the sg driver? From a Unix perspective it means (and Linux
enforces) that you cannot call write(). However using the
sg_header interface you needed to use write() to send a
SCSI INQUIRY to a scsi device. From a SCSI command set
perspective INQUIRY is a read only command. [BTW the
new sg_io_hdr interface permits sg users in lk 2.4 to
open() O_RDONLY and then issue a limited set (including
INQUIRY) of SCSI commands via the SG_IO ioctl() ].
But I digress ...

> Maybe we should also return SANE_STATUS_DEVICE_BUSY on EBUSY.

Sounds reasonable.

Doug Gilbert