Bill Davidsen wrote:
> Actually, in practice it's SCSI-subset over IDE, with most devices
> lacking support for some of the functions. Reconnect is the one which
> comes to mind, I have a list of others someplace.
Ok, use the J�rg idea the, use SCSI to implement ATAPI and deny all
operations that an ATAPI can't do.
On the other hand, if it's a subset, why don't you compile this subset
in ide-cd?? (see later)
> Even though some of us on this list may have had burners for five
> years or more, they are still not particularly common on UNIX systems,
> and many people boot other operating systems to use them even if they
> have them.
Well, this needs to change then.
[EMAIL PROTECTED] wrote:
> > Actually, in practice it's SCSI-subset over IDE, with most devices
> ... but it is defacto a 99% subset ....
> Did you ever look into the ide-cd.c source code from Linux?
>
> All functionality of an ATAPI CD-ROM drive except reading blocks requires
> SCSI commands.
>
> See above, this _is_ the major argument towards an ATAPI integration.
> ide-cd.c duplicates much of the SCSI command compilation code of the
> SCSI CD-ROM driver so why not removing it and only using the SCSI-CD-ROM
> driver for both?
Good question. Now there are two solutions
- implement the subset in ide-cd
- use scsi-cd always (J�rg's idea)
the later seems cleaner. Now I just have one question about bloating the
kernel,
Is it so bloat if you only select "scsi support" and "scsi cd support"??
If it is, then ide-cd and scsi-cdrom should share code, and allow the
extensions
that make my burner work be a module or a compile option.
As Fernan Aguero said in a previous mail, It is just fun to plug and
began to burn.
Thanks,
--
Manuel Clos,
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
