>From [EMAIL PROTECTED] Tue Feb 9 23:02:45 1999
>> > Heiko and I have made a new version more then 9 moths ago an nobody
>> > was willing to incorporate this change.....
>> Possibly because there was no active maintainer at that time, and the
>> new maintainer (Jens) had no idea you'd made improvements. As for
>> Linus' interest/lack of interest, I can't comment; I don't talk to God
>> all that often :-)
>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.
I don't know whether we already talked to each other, but I hardly
tried to get hold of a person who is responsible for sg in August
last year.
At this time it seems that Eric was the right person but had no time.
He also got another patch request fom another person who thought that
it would be a good idea to introduce an iocl interface. UNfortunately, this
interface was not well designed.
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.
we also added a ioctl to retrieve the actual SG_BUF_SIZE
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.
If we in addition add scatter/gather support, this enhancements should
last for 1-2 years.
>I'm doing the Uniform + ATAPI CD-ROM stuff, but I'm following
>your discussions on the side line. I'm quite sure that if people
>put work into redefining and developing a good sg it wouldn't
>go unnoticed. Especially since it is rather flaky as it is...
>> Now we have a number of active developers participating in SG,
>> improving the chances that good ideas will be improved upon and bad
>> ideas will be filtered.
>With the people working on it now, I feel confident about the
>future for sg.
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.
The reason for not doing this now is that this deiver after being
14 years 100% binary compatible now needs some modifications to allow
newer SCSI features and I don't like to add a new interface which
is known to be a subject of change.
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
