Kenneth D. Merry writes:
> > Does this extend to the point of supporting things that happen to
> > share a physical connector with SCSI, but otherwise aren't SCSI?
> > Because that's what supporting non-MMC CD-R drives would amount to.
> Not really.  Non-MMC CD-Rs not only use the same connectors and cables,
> they also comply with the SCSI standard.  They use the same bus protocol,
> respond to inquiries and test unit ready commands just like everything else.
> They also act like standard CDROM drives when you're reading data.  They
> primarily differ in the mechanisms and quirks needed to do writes.

No, they comply with *part* of the SCSI standard - the part needed to
do reads. But drives with the same connectors comply with *part* of
the standard - the part that defines the connector.

> > Of course that isn't the entire picture - that's why I asked. Again,
> > arguing about this solution being "halfway" when you're ignoring half
> > the functionality of the standard seems hypocritical.
> Not really.  We've had a solution for supporting the other (writing) half
> of the standard from the beginning -- cdrecord.  That solution has also
> covered non-MMC drives from the beginning.

I've been told (repeatedly) that ports are *not* part of
FreeBSD. Therefore, we don't have a solution. We have a pointer to one
provided by someone else.

> > > If doing burncd support for MMC drives were a step on the way for getting
> > > support for the various other types of drives that cdrecord supports, it
> > > would be a different story.  (We'd also want to see what features were
> > > available in cdrecord but not burncd and look into adding those as well.)
> > In other words, supporting the standard would only be reasonable if
> > it's a start towards embedding cdrecord in the kernel, which we have
> > already agreed is unreasonable.
> Yes.

That sounds like "I don't want to do it for religious reasons" to me.

> > > As it is, importing cdrecord into the tree would solve what seem to be
> > > your major objections -- that cdrecord gets out of sync with the OS because
> > > it isn't built with the OS, and that we don't ship a way of burning SCSI
> > > CDs with the OS.
> > Your doing that would certainly be a step in the right direction.
> Well, I didn't say I wanted to be the one to do it.  :)  I really know very
> little about vendor branch imports, etc.

Well, you have someone willing to fix the problem - but you object to
the fix for religious reasons. The fix you're willing to accept you're
not willing to implement. Sounds like a bureaucracy to me.

Do you claim ownership of all the drivers in cam/scsi, or can someone
with more tolerant religious convictions add a driver that's a clone
of the CD driver + MMC extensions that gets first crack at CDROM
drives, and recognizes MMC drives, but not others?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to