Kenneth D. Merry writes:
> On Mon, Aug 21, 2000 at 18:19:47 -0500, Mike Meyer wrote:
> > Kenneth D. Merry writes:
> > > > 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.
> > > I think it would generate a fair amount of mail, certainly a lot more than
> > > the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs.
> > > (which is very, very little)
> > What evidence do you have that it would generate a fair amount of
> > mail?
> Prior experience.  People get confused relatively easily, no matter how many
> places something is documented and no matter how many times you explain
> something on a mailing list.

Um - that's not evidence, that's an argument. But prior experience
shows that having two tools for burning cd's generates - in your own
words - "very, very little" mail. By the same argument, including some
drives in both sets of tools shouldn't raise the confusion level.

> > > > 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.
> > > It's not there because I'd rather not do a halfway solution.  Adding
> > > support for only MMC drives will mean that users with non-MMC SCSI CD
> > > burners will just get confused when burncd doesn't work.  ("But it worked
> > > for my friend Joe...")
> > I'd say that you've *already* got a halfway solution, in that you only
> > support half the functionality of the standard. 
> You mean reading and not writing?


> One piece of writing functionality I *do* intend to put in the kernel is
> support for DVD-RAM drives.  (It's mainly hung up with disklabel problems
> at the moment.)

Why those and not CD-R drives? Especially when, from what I can tell,
the situation with those is even *more* confused than it is with
CD-Rs, as there are multiple writable DVD formats, and they are

Or are you talking about support for the non-9660 file system that
some of them use?

> > Just curious - do you feel that you have to support old disk drives
> > that don't properly adhere to the SCSI standard, or otherwise behave
> > in strange ways? Say some of DEC's old drives that don't spin up on
> > power on, but have to be told to do so by the OS? A quick check
> > doesn't reveal any support for such things, but I may have missed it.
> You missed it.  In the error recovery code.  If a drive returns an error
> code that we understand to mean "spin me up", we send a start unit command
> to the disk.  (No more than four start units may be oustanding at one time,
> to avoid overloading power supplies.)
> We also have various quirk tables for devices that do odd things.  So yes,
> I think we do need to support older and/or quirky hardware, to a certain
> point.

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.

Supporting quirky MMC drives should be done just like most other
hardware, though.

> > > Just because the API is there doesn't mean we should go through the work
> > > to support that API when we have something else that already works.
> > > It would be a duplication of functionality.  Why reinvent the wheel
> > > when the wheel we have works very well?
> > For the same reason that CAM replaced the old SCSI system - because
> > the replacement is an improvement! Sure, it won't work with
> > non-standard devices, but those should be a shrinking minority.
> I don't think you've made the case that the replacement is an improvement.
> cdrecord at the moment has more features than burncd, and seems to work
> well.

Well, I don't agree on that assesment about how well cdrecord
works. I've found it to be finicky and a PITA.

> The only thing you've said about cdrecord is that the code is a mess
> (below).  I don't think it's that bad.  I might do things differently,
> but things are going to be more complicated when you try to support a large
> number of OSes.

You forgot the problems of it staying in sync with the OS. I've had
both build breakages, and binaries that quit working after starting to
write a blank (thus ruining it) after doing an OS upgrade.

> > > If you want standard burner support with the OS (isn't that what you're
> > > really getting at here?), why not just import cdrecord into the contrib
> > > tree and be done with it?  It's GPLed, so it wouldn't be any more onerous
> > > license-wise than many of the other tools we have in the tree.
> > Well, that would certainly solve the sync problem - but I'm not
> > willing to support cdrecord; it's an ugly mess. I'd rather support
> > (including write) the MMC code. I just don't want to write it if it
> > will never go in the distribution.
> What you're willing to support isn't the whole picture here.  As the driver
> author, I'd rather not support a solution that only goes halfway.

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.

> 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.

> 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.


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

Reply via email to