Monty (xiphmont@mit.edu)
Tue, 27 Oct 1998 16:58:48 EST
Hi all,
I didn't see any archives of paride stuff for linux to temper this
letter with, so apologies if the subject material has been previously
addressed.
Minor questions and points:-------------------------------------------
The paride documentation contains a few incorrect instructions, and a
few things it doesn't say which it probably should:
The file pg.c states, explicitly, in the source:
"To use this device, you must have the following device
special files defined:
/dev/pg0 b 97 0
/dev/pg1 b 97 1
/dev/pg2 b 97 2
/dev/pg3 b 97 3"
This is incorrect. pg.c implements a character device. The makedev
patch gets it right. Note that nowhere else does the documentation
state what proper major numbers are nor whether the devices are block
or character. I read the actual source to figure out which was right;
the automated script or the comments in the source (obviously the
comments were wrong).
Next, there's no mention of the fact that I can't load pcd and pg at
the same time... Why is this not possible? Considering that the docs
warn me to not use kerneld, do I have to su to root and frob kernel
modules each time I use the CDROM drive for something different? (ie,
cdparanoia wants pg, xmcd what pcd, etc...)
The source also states:
"There are no ioctl() operations. Any single operation
may transfer at most PG_MAX_DATA bytes. Note that the driver must
copy the data through an internal buffer. In keeping with all
current ATAPI devices, command packets are assumed to be exactly
12 bytes in length."
ATAPI devices use both 10 and 12 byte packet commands (there's no 12
byte MODE SENSE, for example). ATAPI does drop all of the 6 byte SCSI
commands however.
Major interface feedback:---------------------------------------------
One:
Why a movable major? What does this serve other than making it even
more difficult to determine what type a device is? Now cdparanoia has
to try three different ways of identifying devices:
By device name (unreliable; the name can be changed)
By 'assigned' major (now also unreliable)
By major /proc entry (also unreliable; not all distributions ship with
/proc support, and this also assumes the module
is already loaded)
Two: (and this is more than a bit of a flame. Sorry about the tone.)
Why was the programmatic interface not implemented through the normal
IDE hooks and generic through scsi emulation like ide-scsi? I'll stick
to what is relevant to me: Linux now has *four* kernel interfaces for
sending raw packet commands to CDROM devices; I have to write seperate
code to support each of them.
The silliness is, of course, that all these different devices with
different interfaces obey the same packet commands. There's just four
(well, three and a half) different ways, depending on device which one
must first identify, to send them. The packets are the same.
This is more than a little absurd, especially considering that the pg
interface essentially copies the style of the sg interface (which was
itself poorly designed and even more poorly implemented; but that's
another story). This very much seems to be another case of 'implement
now, design later'; unfortunately, we're likely stuck with yet another
interface for all of eternity.
I haven't seen the NetBSD people laugh at Linux this hard in a while
(and I agree with them...) We should either *fix* the generic SCSI
interface for good (and put all the hardware specific code behind
that) or write a single new interface and depricate everything else
(both the cleanest and dirtiest solution in different ways...)
Three:
There is no way to at *runtime* query of several crucial elements of
configuration.
As one example, pg.c makes the generic SCSI SG_BIG_BUFF size mistake
all over again. The problem is basically this: You can't directly
find out, runtime, how big the maximum request can be.
No, you *can't* pull it out of the kernel header during build time.
Why? Because a thousand linux machines on a local net (say, MIT) might
all be sharing one executable off of a fileserver but have different
module build configurations. Or, Debian and RedHat might want to
distribute a package. By forcing the setting *for a particular
kernel* to be hardwired into the application at buildtime, you've
eliminated the ability for it to deal with any other setting.
Now I have to find a way to hack around this too. pg.c even managed
to make this harder to detect than sg.c; the generic scsi driver
returns a unique error (ENOMEM) for not being to allocate a buffer
that big. pg.c returns (EINVAL). "But which of all the possible
things did I do wrong?" I hate writing autosense code that has to
keep guessing...
And this is just one example.
(now for some didacticism)
Linux shouldn't be merely functional; we have a responsibility to make
it *right*. It's perfectly OK to look at other OSes and other
people's drives and steal the good ideas and avoid the bad. The
*implementation* of paride appears to be quite good; the functionality
has been flawless (so far) on the test devices I've borrowed for
development. But tactics are only half the battle; strategy is
essential, not just a niceity.
Or I could just say, "Good enough for Windows is *not* good enough for
Linux" :-)
So, all flaming aside, the code works well, but the interface issues
I've raised above I consider to bugs just as significant as the code
only working half the time. I'd like to see these issues addressed
before paride becomes immutable set in time, and it's too late to make
this *right*.
Monty
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:41 EST