Kenneth D. Merry writes:
> On Mon, Aug 21, 2000 at 10:54:49 -0500, Mike Meyer wrote:
> > I'm curious - is there some reason that the CDR ioctls (in
> > /usr/include/sys/cdrio.h) aren't supported for MMC cds? It looks like
> > doing them for MMC would be straightforward, it's the kind of thing
> > that an OS is supposed to do, and it would allow people with MMC
> > drives to cdrecord for the much (much, *much*) smaller burncd.
> Well, doing that sort of thing for MMC-compliant CD-Rs will open the door
> to doing it for all CD-Rs.
No more so than has already been done by supporting SCSI cdrom at all.
> We'd get a flood of mail saying things like "why isn't my froboz CD-R/WORM
> supported with the cd(4) driver..."
Which should actually be smaller than the flood of mail saying things
like "why doesn't burncd support my nice, standard-compliant CD-R?" In
fact, according to the documentation that comes with cdrecord, it
would be *much* smaller, because all the SCSI CD-Rs released in the
last few years have been MMC.
> cdrecord supports a much wider variety of drives out of the box, it is
> actively supported, and it works.
Yup. Since it's native OS isn't FreeBSD, it wouldn't vanish even if we
*did* put all of cdrecord in the kernel. I don't even see the port
vanishing, because of the need to support legacy hardware.
> If we put all of cdrecord's functionality into the kernel and burncd, it
> would be just as big, or bigger than cdrecord is now. (Plus we'd be stuck
> with maintaining it.)
Correct. I'm not asking why cdrecord's functionality isn't in the
kernel, and wouldn't argue that it should be. I'm asking why there
isn't support for a widely deployed standard interface to this
functionality when there's already a kernel API for it.
If it's a matter of not wanting to maintain that little bit of code,
I'm willing to do that.
<mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
