(Sorry for the week delay; work has had me hosed into the ground.) >Concerning the above problem (2 fds on the same 'sg' device) you could >ban it with O_EXCL :-) This is exactly what I do... but it has to be O_EXCL and nonblocking, then change to blocking if it succeeds :-) >Failing that I have implemented the 'pack-id' >concept in the original 'struct sg_header' so you can fetch (read()) >using the pack_id given to the corresponding write(). For a SCSI >read/write command the sector address would be a good candidate for >the pack_id. Some co-operation between to the 2 apps holding those >fds would be desirable. [If they were seperate apps they could use >their pids as pack_ids]. There is still the potential for collision... and I don't like the idea of applications requiring cooperative coding to function together. It's somewhat against UNIX design parameters. How difficult is it to have the kernel keep the operations on a device straight by fd? >According to the MAINTAINERS file in 2.0.36 and 2.2.0-pre7 there is >no current maintainer of 'sg'. Have I been looking in the wrong place? I believe you're correct; there has been no real active maintainence for a long time, just scattershot patches that don't have wide distribution. Until recently that is; it seems like development in the generic packet area has suddently sprung to life again. Seredipity and all that... Monty - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
