Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Aug 2000 22:02:05 -0600
From:      "Kenneth D. Merry" <ken@kdm.org>
To:        Mike Meyer <mwm@mired.org>
Cc:        current@FreeBSD.ORG
Subject:   Re: Why no CDR ioctls for SCSI cds?
Message-ID:  <20000821220205.A73533@panzer.kdm.org>
In-Reply-To: <14753.62883.183839.508028@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 10:38:11PM -0500
References:  <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <14753.50849.16035.805395@guru.mired.org> <20000821212517.B73232@panzer.kdm.org> <14753.62883.183839.508028@guru.mired.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 21, 2000 at 22:38:11 -0500, Mike Meyer wrote:
> Kenneth D. Merry writes:
> > > 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.

That's been good enough for most everyone else....  I said I'm open to
having it in the contrib tree, what more do you want here???

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

*sigh*

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

There are over 200 committers, and there are plenty of them who are capable
of doing it.  I'm willing to support its inclusion in the tree, but what
I'm not willing to do is commit to spending the time to put cdrecord in
the tree and keep it up to date.

Would you rather I stick it in the tree and then never update it for lack
of time?

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

Talk to Matt <mjacob@FreeBSD.org>, or Justin <gibbs@FreeBSD.org>, and see
what they have to say.

Ken
-- 
Kenneth Merry
ken@kdm.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000821220205.A73533>