Messages in this thread |  | | | From | (Eberhard Moenkeberg) | | Subject | Re: Ideas for v2.1 | | Date | 12 Jun 1996 20:01:44 GMT |
| |
Aaron Tiensivu (tiensivu@pilot.msu.edu) wrote: : > : o Adaption of all the CD-ROM drivers to use the generic interface. : > Sounds like "take a screw driver and make all CDROM drives IDE/ATAPI".
: 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
|  |