: That's not an option for everyone. It's nice that someone came up with a
: 'standard' software interface for Linux.. I think it's a good idea.
It is such a great idea that i was fascinated from the beginning, and still
I am.
When I started sbpcd, we just had two "proprietary" CDROM drivers:
Corey Minyard's clean-coded cdu31a and Martin Harriss' easy-to-understand
mcd. These two and the existing <linux/cdrom.h> with a complete set of
audio IOCTLS ported from the Suns and derived from the SCSI-2 standards
were the base. That was our "standard", that is our standard and nothing
else will be THE standard. Even the ATAPI standards will bring only
minor new aspects; there you can see how good the design already is.
Since then, I've "actively watched" the growing of every Linux CDROM driver
for "proprietary" interfaces but one (guess which one not). One important
goal was to keep them all unique at the "user program interface side",
and they in fact are. The differences have a really minor importance, and
most of them are of the type "not implemented yet".
You can check this opinion by running the test programs you find in
linux/Documentation/cdrom/aztcd and sbpcd with other drivers.
The existing standard <linux/cdrom.h> has evolved a lot, and we did it in
a way to respect hard disk standards and the sun audio CD standard.
Now we will continue doing this.
We will NOT introduce lots of new fancy "user callable" subroutines; this
would end up in two classes of related "user programs": "Linux only"
and "portable". Not a goal, not even a secondary goal.
There is no need to blow up the set of "user callable functions", and
we would have no chance to "export" this layer to other unixes.
We will NOT introduce an additional software layer between the driver and
the program. To open a file or a device, the open call will not go to a
new layer first from where the driver's open routine gets called, for
example.
There will be work to unify the "non drive-specific" code within all
Linux CDROM drivers; it has to get done by each driver writer himself,
under guidance of David van Leeuwen's "standard" proposal and maybe a
"closed" Linux CDROM driver writer mailing list.
This will lead to a refinement of the existing <linux/cdrom.h>, not to
a new standard.
A possible next step then will be to take that "non-specific" code out
of the drivers; this merely makes sense if we can put it into a "function
library" under drivers/cdrom/.
If you read David's text under these aspects again, you probably will
see that we will not introduce a "new design", but merely a "cross check
for unified behavior".
Got a more general answer, so don't take it too personally.
I don't like to see enthusiasm about "design papers"; small pieces
of internal work is what we need.
So, let me end up here; I will try to respond to other aspects of
your answer separately.
Cheers -e
--
Eberhard Moenkeberg GGG W W DDDD GGG
G W W D D G
E-Mail: emoenke@gwdg.de G GGG W W D D G GGG
Phone: +49 551 2011551 Fax: +49 551 21119 G G W W W D D G G
SnailMail: GGG WW WW DDDD GGG
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg, D-37077 Goettingen, GERMANY
At home: Modem+ISDN ("guest") ++49-551-7704102, ISDN-HDLC 7704103