Monty wrote:
>
> >Hello,
> >I have been working on enhancing the linux sg driver for a while now
> >and you may like to try it. It has the following features:
>
> First I've heard of it... Is it too late for input? (I'm not on the
No it is not.
> linux-scsi list, although it sounds relevant; subscription
> instructions please? Not that I need to add to a six-hour-a-day email
> habit, but I had better be subbed if I'm going to contribute...)
Email [EMAIL PROTECTED] and put the line
"subscribe linux-scsi"
in the body of the message. To get off the list change 'subscribe' to
'unsubscribe'. It is a relatively low volume newsgroup though the volume
has picked up recently (ie around 4 or 5 emails a day).
> As one of the developers pushing the Linux SG driver hardest (the
> Paranoia project), I'm of the opinion that the driver does not need to
> be enhanced; it needs to be replaced with something that wasn't
> originally cobbled together for a single application. The design was
> underpowered, the implementation badly flawed.
Your opinion seems to be similar to Joerg Schilling (author of cdrecord)
who also thinks it should be thrown out and replaced with something like
the 'scg' interface that he wrote for Sun equipment (copyrighted in
1986).
I believe he is working on something with Heiko Eissfeldt and I would
have expected to see some output by now. I have emailed both these
gentleman and Eric Youngdale canvassing their opinions.
The only advantage of using and extending the existing interface is
backward compatibility with a lot of existing applications. I replied
to GOTO Masanori because he described a serious flaw of the
original implementation in which 2 sg devices are accessed and they
contend for the SG_BIG_BUFF. My implementation should cure that
without (hopefully) any side effects. Also he is actively developing,
so changing his interface to try out some of the extensions should
not be too difficult.
> I've read the rest of your message below describing enhancements; it
> appears you have a pretty good grip on what SG needs to do, what
> needed to be corrected and how to do it, so I don't think I need to do
> any flaming. I have a few questions, and I'd like to offer one
> important 'demand' that I consider vital to Linux in general.
Using the existing sg interface (plus some extensions) is the easiest
way for alpha tester to evaluate my implementation. I am not wedded
to that interface and if the implementation is strong enough its
interface could be changed, or multiple interfaces could be given
to the same implementation.
> What needs to happen to SG, PG, ATAPI, et al is not a piecemeil
> improvement of a single interface that further complicates
> compatability issues for minimal gain, but a redesign and unification
> that takes into account the practical programming experience of the
> folks using it as well as the wisdom of preceeding systems. Above all
> the interfaces must be *uniform*. If we're going to break with a
> current interface, I'd like to see Linux go all out, break totally
> with what's there and get a new interface set that's clean and above
> all unified (right now, Paranoia has seperate Linux code at various
> levels for ATAPI cooked ioctl() interfaces, ATAPI using SG with
> IDE-SCSI, generic SCSI, and PG the parallel port raw ATAPI interface.
> This is rediculous. And Joerg: No flames. Alpha 10 is based heavily
> on your code at the transport level ;-).
This all sounds extremely sensible.
> Before the high-level driver holy wars start again, I'm aware of the
> limitations of Linux's internal VFS and device layers. There's no
> practical way, without redesigning the kernel, or acheiving true
> unification of the interfaces through a single kernel device. What
> *is* possible is design of a uniform generic interface standard that
> is enforced across the different hardware devices such that in user
> space the divisions are seamless. All four of the above obey the same
> commands, dammit!
Well then you will need those 4 drivers to be actively maintained and
the individuals concerned prepared to work with one another and once
a unified interface is in place, collectively reject most, but not all,
suggestions from the application writers :-)
> I realize that you worried about compatability. Unfortunately, the
> old SG is so riddled with bugs that I'm relying heavily on some of
> those bugs (including a kernel buffer clobber) to get around driver
> shortcomings in Paranoia. The result of a better, but very similar,
> interface is that I'll need new heuristics to seperate old from new,
> and still have to treat both differently. If I already have to deal
> with 'old' versus 'new', let's go for it and make the dichotomy
> worthwhile.
Didn't know about the kernel buffer clobber, tell me more (perchance
I replicated that feature).
In my implementation's case doing a "#ifdef SG_SCATTER_SZ" or a
"ioctl(sg_fd, SG_GET_PACK_ID ...)" will differentiate the original sg
driver from my driver. Perhaps there should be a version number in
there as well...
> You obviously have a firm grip of the state of SG and how to implement
> better. Grant Guenther (author of the PG interface) has also told me
> that he'd like to see such a unified interface and is willing in
> general to move PG to such an interface. We have, unfortunately, lost
> Gadi Oxman (author of SCSI-IDE emulation) to the real world, but
> perhaps he's still willing to offer advice.
There should be no problem at this end co-operating with these people.
After some frustation using dd on large disks (ie it seems to use
a 32 bit byte pointer) my current project is to write a "sg_dd512"
program that has a "dd" like interface where one or both of the
given files (if, of) are scsi generic devices. It should be useful
for measuring performance of the sg implementation (and the scsi
hardware) as well.
------------------------------------------------------------------
Douglas Gilbert [[EMAIL PROTECTED] or [EMAIL PROTECTED]]
48 Windsor Court Road Web: www.interlog.com/~dgilbert
Thornhill, Ontario L3T 4Y5, Canada Tel: +1 905 771 6151
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
