[5705] in linux-scsi channel archive
Re: ATAPI/SG/PG unification? was: Re: patch for cdparanoia
daemon@ATHENA.MIT.EDU (Monty)
Tue Jan 26 21:24:54 1999
From: Monty <xiphmont@mit.edu>
To: Douglas Gilbert <dgilbert@interlog.com>
Cc: axboe@image.dk, dougg@smtp.interlog.com,
linux-scsi@vger.rutgers.edu, xiphmont@MIT.EDU, grant@torque.net,
gadio@netvision.net.il, heiko_eissfeldt@z.detesystem.de
In-reply-to: Your message of "Sun, 17 Jan 1999 12:47:57 EST."
<36A2224D.46A65EF6@interlog.com>
Date: Tue, 26 Jan 1999 20:27:16 EST
(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 majordomo@vger.rutgers.edu
