Re: Why no CDR ioctls for SCSI cds?
In list.freebsd-current Kenneth D. Merry [EMAIL PROTECTED] wrote: On Tue, Aug 22, 2000 at 20:43:15 -0400, Laurence Berland wrote: On a vaguely related topic, after much searching I can't seem to see one way or the other if we can do a complete bit-by-bit copy of a cd with either cdrecord or burncd, though it's possible I'm looking in the wrong place. I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in ports/audio) can do it as well. As far as getting an image, you can use dd to dump off an image of a CD if it is a standard ISO9660 CD. (I've used that method to clone CDs before.) If it uses a blocksize other than 2048 bytes, though, you can't use dd with the SCSI cd driver. There may be CD rippers that can pull the data off into an image, though. I don't know for sure. Tosha can read tracks from CDs with 2352 byte blocks, for example VideoCDs. I'm using it sometimes to directly pipe the data into MpegTV to view VCDs under FreeBSD. (BTW, tosha can also read standard data tracks with 2048 byte blocks. While dd provides the same functionality, tosha has a few nice features such as a progress and ETA display, which might make it preferable over dd.) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) Addresses will change soon!! If in doubt: www.fromme.com "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
It seems Mike Meyer wrote: I'm planning on implementing all the CDR ioctls for SCSI cds. BTW, are those documented somewhere? I mean, I can work out what they should do, but they still ought to be on a man page. Soren? Uhm, no man page I'm afraid, but I'll answer any questions you might have... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
It seems Laurence Berland wrote: On a vaguely related topic, after much searching I can't seem to see one way or the other if we can do a complete bit-by-bit copy of a cd with either cdrecord or burncd, though it's possible I'm looking in the wrong place. Uhm, I've had some success with changing the READ_CD flags in atapi-cd from 0x10 to 0xf8, that will make the driver read the entire block (2352bytes) no matter what format it is. Then burning it is bitch since DAO mode is not in the official sources yet, but with a bit of enginuity it can be done.. Or use cdrdao on a SCSI burner... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
"Kenneth D. Merry" wrote: On Tue, Aug 22, 2000 at 20:43:15 -0400, Laurence Berland wrote: On a vaguely related topic, after much searching I can't seem to see one way or the other if we can do a complete bit-by-bit copy of a cd with either cdrecord or burncd, though it's possible I'm looking in the wrong place. I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in ports/audio) can do it as well. As far as getting an image, you can use dd to dump off an image of a CD if it is a standard ISO9660 CD. (I've used that method to clone CDs before.) That didn't seem to work when I tried it a couple of days ago. Got a "device not configured" error. Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On 23 Aug, Paul Richards wrote: On a vaguely related topic, after much searching I can't seem to see one way or the other if we can do a complete bit-by-bit copy of a cd with either cdrecord or burncd, though it's possible I'm looking in the wrong place. I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in ports/audio) can do it as well. As far as getting an image, you can use dd to dump off an image of a CD if it is a standard ISO9660 CD. (I've used that method to clone CDs before.) That didn't seem to work when I tried it a couple of days ago. Got a "device not configured" error. You've done something wrong, it works here. BTW: If I need a copy of a data cd I use "cdrecord -v speed=4 dev=0,1,0 -eject -isosize /dev/cd1c" (cd1 is my CD-ROM, cd0 (dev=0,1,0) is my CD burner). Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Alexander Leidinger wrote: On 23 Aug, Paul Richards wrote: On a vaguely related topic, after much searching I can't seem to see one way or the other if we can do a complete bit-by-bit copy of a cd with either cdrecord or burncd, though it's possible I'm looking in the wrong place. I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in ports/audio) can do it as well. As far as getting an image, you can use dd to dump off an image of a CD if it is a standard ISO9660 CD. (I've used that method to clone CDs before.) That didn't seem to work when I tried it a couple of days ago. Got a "device not configured" error. You've done something wrong, it works here. Yep, just tried it again and you're right I was doing something wrong. I was trying to dd from the blank in the CD-RW rather than the master in the CD (blush). BTW: If I need a copy of a data cd I use "cdrecord -v speed=4 dev=0,1,0 -eject -isosize /dev/cd1c" (cd1 is my CD-ROM, cd0 (dev=0,1,0) is my CD burner). That's what I used in the end. Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
In message [EMAIL PROTECTED] Mike Meyer writes: : 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? Ken wrote the cd driver as well as large parts of CAM. Chances are good that what you are calling religious convictions were actually hard fought engineering decisions that have the backing of hard experience plus many more "details" that Ken might not recall off the top of his head but that lead to his views. Having said this, if you can come up with a foolproof way to get the ioctls right on all the drives that do support them, even the whacked out ones that need all kinds of quirky entries, and do it in a way that doesn't needlessly bloat the kernel for little gain (few people, in the scheme of things, have cd-r or cd-rw on their machines and use them to burn disks), then he might reconsider his views. However, much of your posts have had an "airchair quarterback" feel to them and unless and until you have working code, nobody's opinions are going to change. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 10:50:11PM -0500, Mike Meyer wrote: Christopher Masto writes: I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. As cdrecord isn't part of FreeBSD, this is clearly the wrong place to ask about that. Joe Schilling watches [EMAIL PROTECTED], and that's the place to ask. I've been told that ATAPI CD-Rs use the same basic command set (MMC) as SCSI ones, only they don't have legacy problems - so it should be possible. Actually, that's why this would be the appropriate place. cdrecord is designed to do that sort of thing - it separates out the driver interface and has several already, including support for Linux's "ATAPI over SCSI". It just doesn't work with FreeBSD because our ATAPI driver doesn't make available the low-level communication it needs. But whatever. I've personally decided to give up on it and get a SCSI CD-R at some point. I'm just confused by the desire to avoid cdrecord, since in my experience, it has worked great. It also has a lot of nifty options. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Warner Losh writes: Having said this, if you can come up with a foolproof way to get the ioctls right on all the drives that do support them, even the whacked out ones that need all kinds of quirky entries, and do it in a way that doesn't needlessly bloat the kernel for little gain (few people, in the scheme of things, have cd-r or cd-rw on their machines and use them to burn disks), then he might reconsider his views. However, much of your posts have had an "airchair quarterback" feel to them and unless and until you have working code, nobody's opinions are going to change. You may well be right, and there are good technical reasons for not doing this. The only real reason that's been presented for not doing MMC is that all the non-MMC drives might cause a support headache. There are sound technical reasons for *not* doing non-MMC drives, and Ken and I agree on that. If the answer from the person who would have to approve the code had come back "Ok, provide the code and we'll see how well it works in practice", I'd do the code. But when it appears the code would never make it into the tree to be used, why waste my time? mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
If the answer from the person who would have to approve the code had come back "Ok, provide the code and we'll see how well it works in practice", I'd do the code. But when it appears the code would never make it into the tree to be used, why waste my time? 'coz we're taking a page from Linus. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
In message [EMAIL PROTECTED] Mike Meyer writes: : You may well be right, and there are good technical reasons for not : doing this. The only real reason that's been presented for not doing : MMC is that all the non-MMC drives might cause a support : headache. There are sound technical reasons for *not* doing non-MMC : drives, and Ken and I agree on that. Actually, the real reason is that MMC drives that mostly support the standard, but do it wrong in ways that are hard to detect. Those are going to be the worst to try to support. There are some drives out there that just hang when you issue them certain MMC commands, as an example. They shouldn't but they do and you have to be careful not to send them these commands. : If the answer from the person who would have to approve the code had : come back "Ok, provide the code and we'll see how well it works in : practice", I'd do the code. But when it appears the code would never : make it into the tree to be used, why waste my time? I think that you overstate ken's reluctance. If you can come up with a good way to deal with this and have a good error mechanism for those drives that don't support this then I think he might (and I repeat might) be talked into it. I've found Ken quite accepting of code in the past when I've gone to the trouble of doing something. I've found in the past that working code has a way of making people reconsider their opinions of things. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Matthew Jacob writes: If the answer from the person who would have to approve the code had come back "Ok, provide the code and we'll see how well it works in practice", I'd do the code. But when it appears the code would never make it into the tree to be used, why waste my time? 'coz we're taking a page from Linus. Does Linus tell people something is a bad idea, and then use it anyway? Or does he just not bother to respond to questions about whether or not something would be a usefull addition? mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
-On [2822 08:50], Warner Losh ([EMAIL PROTECTED]) wrote: Actually, the real reason is that MMC drives that mostly support the standard, but do it wrong in ways that are hard to detect. Those are going to be the worst to try to support. There are some drives out there that just hang when you issue them certain MMC commands, as an example. They shouldn't but they do and you have to be careful not to send them these commands. This got parsed by me as: mmc-quirk.h It wouldn't be hard to keep it tracked in a quirk file as per the SCSI disk quirk file. But I am not sure it is elegant. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl There is no joy in smallness. Joy is in the infinite... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
-On [2822 06:25], Kenneth D. Merry ([EMAIL PROTECTED]) wrote: It needs an ATAPI passthrough mechanism to work. (FreeBSD doesn't have one at the moment.) Søren, Matt and me were discussing the ATA/CAM issues so that we might be able to approach ATA through CAM. That would clear a lot. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Another morning, black sunday, coming down again... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
One thing that's missing is the ioctl CDRIOCSETBLOCKSIZE. It would be _really_ nice if cd(4) supported that ioctl so I could just seek and read from a CD. I had knu trying out my read_cd program, and it doesn't work for SCSI CD-ROMs, seemingly because of this issue :( Would you be adverse to implementeing that ioctl? -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Tue, Aug 22, 2000 at 15:22:05 -0400, Brian Fundakowski Feldman wrote: One thing that's missing is the ioctl CDRIOCSETBLOCKSIZE. It would be _really_ nice if cd(4) supported that ioctl so I could just seek and read from a CD. I had knu trying out my read_cd program, and it doesn't work for SCSI CD-ROMs, seemingly because of this issue :( Would you be adverse to implementeing that ioctl? That's fine. As it turns out, I've had additional discussions with Mike Meyer and Matt Jacob and Mike will probably be implementing MMC CD-R support. That ioctl will probably be a part of it. The functionality you're looking for is part of a larger issue of supporting CDDA reads in the cd(4) driver. That's needed to support AudioFS. (As well as to support doing a straight read off the CD when an audio CD is in there.) The main problem is that different drives use different commands to read audio data. MMC-compliant drives are one case, but there are a lot more drives out there that use varying methods to read audio data. It'll also take some tweaking to get the driver to support blocksizes that aren't multiples of 512 bytes. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On a vaguely related topic, after much searching I can't seem to see one way or the other if we can do a complete bit-by-bit copy of a cd with either cdrecord or burncd, though it's possible I'm looking in the wrong place. Laurence "Kenneth D. Merry" wrote: [snip] -- Laurence Berland Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. http://stuy.debate.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Tue, Aug 22, 2000 at 20:43:15 -0400, Laurence Berland wrote: On a vaguely related topic, after much searching I can't seem to see one way or the other if we can do a complete bit-by-bit copy of a cd with either cdrecord or burncd, though it's possible I'm looking in the wrong place. I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in ports/audio) can do it as well. As far as getting an image, you can use dd to dump off an image of a CD if it is a standard ISO9660 CD. (I've used that method to clone CDs before.) If it uses a blocksize other than 2048 bytes, though, you can't use dd with the SCSI cd driver. There may be CD rippers that can pull the data off into an image, though. I don't know for sure. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Brian Fundakowski Feldman writes: One thing that's missing is the ioctl CDRIOCSETBLOCKSIZE. It would be _really_ nice if cd(4) supported that ioctl so I could just seek and read from a CD. I had knu trying out my read_cd program, and it doesn't work for SCSI CD-ROMs, seemingly because of this issue :( Yup - none of the CDR ioctls (and that's one) are supported by cd. Would you be adverse to implementeing that ioctl? I'm planning on implementing all the CDR ioctls for SCSI cds. BTW, are those documented somewhere? I mean, I can work out what they should do, but they still ought to be on a man page. Soren? Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
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. We'd get a flood of mail saying things like "why isn't my froboz CD-R/WORM supported with the cd(4) driver..." cdrecord supports a much wider variety of drives out of the box, it is actively supported, and it works. 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.) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
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
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 17:01:20 -0500, Mike Meyer wrote:
Kenneth D. Merry writes:
On Mon, Aug 21, 2000 at 10:54:49 -0500, Mike Meyer wrote:
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.
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)
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.
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...")
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?
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.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
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? I agree that there's very little about burncd - probably because
most people get dual pointers when they ask what to use to record
cds. Improving what burncd works for shouldn't change that, especially
if the kernel boot sequence said whether or not the drive supported
MMC.
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.
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.
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.
This also solves the problem of keeping the two in sync. I've been bit
more than once by the system and cdrecord being out of sync.
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.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
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.
It might not be that bad, though, since cdrecord would still be available
and still work.
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.)
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.
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.
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.
This also solves the problem of keeping the two in sync. I've been bit
more than once by the system and cdrecord being out of sync.
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.
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.)
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.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
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?
Yes.
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
changing.
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
Re: Why no CDR ioctls for SCSI cds?
I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 19:17:37 -0500, Mike Meyer wrote: 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. Hopefully not, but people have a tendency to make simple things complicated. :) 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 changing. Or are you talking about support for the non-9660 file system that some of them use? Well, DVD-RAM drives have a totally different read/write model than CD-R or CD-RW drives. They function pretty much like a MO disk, at least when there is a writable disk in them. Supporting them, at least minimally, is a one line change. (To add write support to the cdevsw in the driver. They really are that much like disks. There's really no additional detection required, since the drive will spit out the command if the media isn't writeable.) CD-R's don't fit within the normal Unix read/write semantics, thus the reason that we have to use userland programs and an ioctl mechanism (whether with burncd or cdrecord) in order to go through the different states required to get the data written. You can't just say "write" and be done. You have to fixate, etc. I'm not working on filesystems at all. Several other folks have talked about doing UDF support, and I'm not really up for tackling that anyway. You can put a UFS filesystem on a DVD-RAM, or you can put an ISO9660 filesystem on one, or whatever other filesystem you want. All I'm working on is the driver-level mechanism to enable write support. 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. 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. 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
Re: Why no CDR ioctls for SCSI cds?
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? mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Christopher Masto writes: I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. As cdrecord isn't part of FreeBSD, this is clearly the wrong place to ask about that. Joe Schilling watches [EMAIL PROTECTED], and that's the place to ask. I've been told that ATAPI CD-Rs use the same basic command set (MMC) as SCSI ones, only they don't have legacy problems - so it should be possible. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
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 [EMAIL PROTECTED], or Justin [EMAIL PROTECTED], and see what they have to say. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
I'm sorry- I really haven't been paying much attention to this, but it seems it's sort of on the wrong mailing list, isn't it? Mike- can you take a deep breath and send a summary of what you see the techical problems/requirements are to the freebsd-scsi alias? I'll admit that I'm not up on a lot of this...oops- I just saw mail from you... taking offline To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Christopher Masto writes: I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. Spoke to soon - according to the pkg/DESCR file, it should work on them now. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 23:18:50 -0500, Mike Meyer wrote: Christopher Masto writes: I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. Spoke to soon - according to the pkg/DESCR file, it should work on them now. It needs an ATAPI passthrough mechanism to work. (FreeBSD doesn't have one at the moment.) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
