Jens wrote:
>I think we have talked passed each other, Monty. The only thing I
>ever did for sg was ripping out the hardsect (which made mounting
>ext2 cd-roms impossible) changes that went in between 2.0 and
>2.2.
Ah, I may be misrememebring what (I thought) you said about becoming
SG's active maintainer then... Apologies.
Jvrg wrote:
>Heiko and I enhanced the sg driver last year as a preparation for a
>complete rewrite. For this reason, It was inportant to retain binary
>and source compatibility. My enhancement that allows to get more
>information from the kernel to the user is in fact source/binary up/downwards
>compatible. It re-uses some of the fields in the sg_header to
>make it
>
>1) possible to specify the SCSI cdb length
>
>2) specify wanted/actual sence count
>
>3) return the DMA residual count (needs to be added to the lover level
> kernel functions to).
>
>4) return the SCSI status byte and the host adapter error reason.
All good things
>we also added a ioctl to retrieve the actual SG_BUF_SIZE
Well, eliminating the need for it would be best, but I'll leave that up
to the implementers. They have a better grasp of buffering complexities...
We do need to know the maximum possible request size tho.
>Later, Heiko added support for allocation of the buffer on request.
>It now turns out, that this code (as a result of a discussion between Heiko
>and me) has a design bug if combined with the cdrecord -scanbus code.
>But this bug may easily fixed.
And cdparanoia (although not as easily; I close the fds after
inquiring, but multiple opens/closes can still cause the ENOMEM). The
bug is simply easier to see with cdrecord.
>I hope, that in about 2 years, the sg driver will be replaced by my
>scg driver which I initially wrote in 1986 for SunOS/Solaris.
I would welcome even this overall, but I disagree with the device
addressing scheme of SCG and CAM. It introduces an artificial
dichotomy between the specialized and generic interfaces, resulting in
more complex application code (or more likely, lazy application code
that dumps the responsibility for matching up devices onto the user).
/dev/sg devices should exist only as placeholders, not a primary
access mechanism.
What are your objections to the BSD style ioctl() interface where
every specialized device has a generic interaction ioctl? I'm not
referring to specific implementation problems, but rather the idea of
presenting a generic interface via the specialized scsi device file
entry. I'm not denying one needs access to the BUS/TARGET/LUN
numbers, just that these details should not be the responsibility of
an unsuspecting user. It would be like naming a serial port
'0x3f8,irq4' and attaching it to /dev/iogeneric1 (UNIX used to do
things sorta this way before the idea of specialized interfaces caught
on. All device drivers were in userspace and applications had to
include device drivers for all the specific hardware they wanted to
use. I'd like to think that BSD4.2 was an overall advance in moving
away from this) instead of just opening /dev/cua0 (and having links to
/dev/modem and /dev/serial0).
All this hunting and error prone device mapping isn't necessary if one
lets go of elevating SCSI over the design idiom of the native OS.
Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
