Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
.. and if someone would like to contribute patches to burncd to update it, I think there'd be at least one committer here who would be happy to help you get your changes into the tree. :-) Adrian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, 26 Sep 2011, Craig Rodrigues wrote: On Mon, Sep 26, 2011 at 8:30 PM, Garrett Cooper wrote: ... Please fix it and move on. Thanks, -Garrett $ usr.sbin/burncd/burncd -f /dev/cd0 blank burncd: device provided not an acd(4) device: /dev/cd0. Please verify that your kernel is built with acd(4) and the beforementioned device is supported by acd(4). Hi, That patch is an improvement over the existing behavior. However, we may want to go a bit farther. Here are some possible scenarios: (1) User has a system with ATAPI CD-ROM only. Covered. (2) User has a system with ATAPI CD-ROM *and* USB CD-ROM. First case covered. Second case requires cdrecord anyhow, so don't care. (3) User has a system with USB CD-ROM only. Second case requires cdrecord anyhow, so don't care. (4) User has a system with ATAPI CD-ROM and SCSI CD-ROM Same as (2). (5) User has a system with SCSI CD-ROM only Same as (3). I would guess that (1) is the most common scenario, and end-users will definitely encounter it and complain. In the case of (1), it would be nice if we could fail if we try to burn to /dev/cd0, as per your patch, but still check to see if ATA_CAM is enabled in the kernel, and print out a message with pointers for using cdrtools. With your patch, a user will see a message about acd(4), and try to get it to compile/kldload/whatever acd(4) on their system, and then not get it to work because ATA_CAM is enabled. Adding notes to the burncd man page that burncd will not work on ATAPI devices if ATA_CAM is enabled would be good to do also. If the long term plan is to get rid of the old ATA subsystem, and completely move to ATA_CAM, then we should put a deprecation warning in the burncd man page as well, to give users a further heads-up. Noting something in the documentation is fine. The point is that there's a lot of wasted electrons being tossed about about a fairly trivial issue: most of the apps that burn/use CDs were converted over to some logic long ago that matches cdrecord. The only apps that haven't really been (atacontrol, burncd) were abandoned because the developer isn't an active maintainer. Thanks, -Garrett___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 8:30 PM, Garrett Cooper wrote: > > ... > > Please fix it and move on. > Thanks, > -Garrett > > $ usr.sbin/burncd/burncd -f /dev/cd0 blank > burncd: device provided not an acd(4) device: /dev/cd0. > > Please verify that your kernel is built with acd(4) and the beforementioned > device is supported by acd(4). Hi, That patch is an improvement over the existing behavior. However, we may want to go a bit farther. Here are some possible scenarios: (1) User has a system with ATAPI CD-ROM only. (2) User has a system with ATAPI CD-ROM *and* USB CD-ROM. (3) User has a system with USB CD-ROM only. (4) User has a system with ATAPI CD-ROM and SCSI CD-ROM (5) User has a system with SCSI CD-ROM only I would guess that (1) is the most common scenario, and end-users will definitely encounter it and complain. In the case of (1), it would be nice if we could fail if we try to burn to /dev/cd0, as per your patch, but still check to see if ATA_CAM is enabled in the kernel, and print out a message with pointers for using cdrtools. With your patch, a user will see a message about acd(4), and try to get it to compile/kldload/whatever acd(4) on their system, and then not get it to work because ATA_CAM is enabled. Adding notes to the burncd man page that burncd will not work on ATAPI devices if ATA_CAM is enabled would be good to do also. If the long term plan is to get rid of the old ATA subsystem, and completely move to ATA_CAM, then we should put a deprecation warning in the burncd man page as well, to give users a further heads-up. -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, 26 Sep 2011, Craig Rodrigues wrote:
On Mon, Sep 26, 2011 at 6:58 PM, Doug Barton wrote:
I have used burncd on many releases of FreeBSD, on many machines
without problem. I can see the fact that burncd suddenly failing to
work on ATAPI hardware could annoy and confused end-users.
It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which
is a SCSI device. The fact that it's emulated doesn't matter.
True, but the subtlety of that distinction will be lost on a lot of end-users
not familiar with the implementation of the FreeBSD storage implementation.
To them "burncd just doesn't work, when it used to".
Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out
a more useful error message?
Sure, as soon as someone volunteers to create that patch. No one is
*trying* to annoy users, but things change around here because people
are interested in changing them.
I am not familiar enough with the ATA_CAM work. Is there a a sysctl or ioctl
that can be queried from userspace to detect if ATA_CAM is configured
in the kernel?
I would suggest something like:
...
Please fix it and move on.
Thanks,
-Garrett
$ usr.sbin/burncd/burncd -f /dev/cd0 blank
burncd: device provided not an acd(4) device: /dev/cd0.
Please verify that your kernel is built with acd(4) and the beforementioned
device is supported by acd(4).Index: usr.sbin/burncd/burncd.c
===
--- usr.sbin/burncd/burncd.c(revision 225704)
+++ usr.sbin/burncd/burncd.c(working copy)
@@ -159,8 +159,16 @@
if ((fd = open(dev, O_RDWR, 0)) < 0)
err(EX_NOINPUT, "open(%s)", dev);
- if (ioctl(fd, CDRIOCGETBLOCKSIZE, &saved_block_size) < 0)
- err(EX_IOERR, "ioctl(CDRIOCGETBLOCKSIZE)");
+ if (ioctl(fd, CDRIOCGETBLOCKSIZE, &saved_block_size) < 0) {
+ if (errno == ENOTTY)
+ errx(EX_IOERR,
+ "device provided not an acd(4) device: %s.\n\n"
+ "Please verify that your kernel is built with "
+ "acd(4) and the beforementioned device is "
+ "supported by acd(4).", dev);
+ else
+ err(EX_IOERR, "ioctl(CDRIOCGETBLOCKSIZE)");
+ }
if (ioctl(fd, CDRIOCWRITESPEED, &speed) < 0)
err(EX_IOERR, "ioctl(CDRIOCWRITESPEED)");
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 6:28 PM, Doug Barton wrote: >> burncd has been part of the system utilities included in the basic >> release since release 4.0 and cdrecord is a port. The professional >> solution is to remove burncd from the 9.0 system release and add the >> cdrecord command to the basic release as the replacement for burncd. >> Then add release notes entry of the change. > > I think you misunderstand the situation. So here are a few hopefully > helpful facts: > > 1. The fact that something is in the base, or in the ports, has > absolutely no bearing on whether one piece of software is fundamentally > more useful or valuable than another. Hi, I have used burncd on many releases of FreeBSD, on many machines without problem. I can see the fact that burncd suddenly failing to work on ATAPI hardware could annoy and confused end-users. Fbsd8 has a valid point. Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out a more useful error message? "ERROR: burncd does not work when ATAPI-CAM driver enabled. Install the sysutils/cdrtools port and use cdrecord instead. Please refer to http://www.freebsd.org/doc/handbook/creating-cds.html#CDRECORD"; While it is necessary to document all these things in release notes, documentation, etc., I don't always read every single last line of documentation or release notes when using a system, and I suspect many end-users are the same. :) I am a big fan of having the system issue diagnostic errors that give the user a clue how to remedy the problem, or pointers to relevant information. I even put "Please" in the error message to be nice. :) -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 6:58 PM, Doug Barton wrote:
>>
>> I have used burncd on many releases of FreeBSD, on many machines
>> without problem. I can see the fact that burncd suddenly failing to
>> work on ATAPI hardware could annoy and confused end-users.
>
> It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which
> is a SCSI device. The fact that it's emulated doesn't matter.
True, but the subtlety of that distinction will be lost on a lot of end-users
not familiar with the implementation of the FreeBSD storage implementation.
To them "burncd just doesn't work, when it used to".
>> Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out
>> a more useful error message?
>
> Sure, as soon as someone volunteers to create that patch. No one is
> *trying* to annoy users, but things change around here because people
> are interested in changing them.
I am not familiar enough with the ATA_CAM work. Is there a a sysctl or ioctl
that can be queried from userspace to detect if ATA_CAM is configured
in the kernel?
I would suggest something like:
flag = query for hw.ata.ata_cam_enabled sysctl;
if (flag == 1) {
printf("ERROR: ATA_CAM enabled, etc., etc.)
exit(1);
}
I only see these sysctls on a system with ATA_CAM enabled:
hw.ata.setmax: 0
hw.ata.wc: 1
hw.ata.atapi_dma: 1
hw.ata.ata_dma_check_80pin: 1
hw.ata.ata_dma: 1
dev.atapci.0.%desc: Intel ATA controller
dev.atapci.0.%driver: atapci
dev.atapci.0.%location: slot=3 function=2
dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x29b6 subvendor=0x1028
subdevice=0x0211 class=0x010185
dev.atapci.0.%parent: pci0
dev.ata.2.%desc: ATA channel 0
dev.ata.2.%driver: ata
dev.ata.2.%location: channel=0
dev.ata.2.%parent: atapci0
dev.ata.3.%desc: ATA channel 1
dev.ata.3.%driver: ata
dev.ata.3.%location: channel=1
dev.ata.3.%parent: atapci0
dev.ata.0.%driver: ata
dev.ata.0.%parent: isa0
dev.ata.1.%driver: ata
dev.ata.1.%parent: isa0
--
Craig Rodrigues
rodr...@crodrigues.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 09/26/2011 18:43, Craig Rodrigues wrote: > On Mon, Sep 26, 2011 at 6:28 PM, Doug Barton wrote: >>> burncd has been part of the system utilities included in the basic >>> release since release 4.0 and cdrecord is a port. The professional >>> solution is to remove burncd from the 9.0 system release and add the >>> cdrecord command to the basic release as the replacement for burncd. >>> Then add release notes entry of the change. >> >> I think you misunderstand the situation. So here are a few hopefully >> helpful facts: >> >> 1. The fact that something is in the base, or in the ports, has >> absolutely no bearing on whether one piece of software is fundamentally >> more useful or valuable than another. > > > Hi, > > I have used burncd on many releases of FreeBSD, on many machines > without problem. I can see the fact that burncd suddenly failing to > work on ATAPI hardware could annoy and confused end-users. It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which is a SCSI device. The fact that it's emulated doesn't matter. > Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out > a more useful error message? Sure, as soon as someone volunteers to create that patch. No one is *trying* to annoy users, but things change around here because people are interested in changing them. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 09/26/2011 17:59, Fbsd8 wrote: > Your solution is very un-professional. Good thing we're all volunteers. :) > What your solution purposes to do > is do nothing. I think your judgment is flawed and a larger group of > your peers need to review your judgment in this case. Ok, done. Eitan is right. > burncd has been part of the system utilities included in the basic > release since release 4.0 and cdrecord is a port. The professional > solution is to remove burncd from the 9.0 system release and add the > cdrecord command to the basic release as the replacement for burncd. > Then add release notes entry of the change. I think you misunderstand the situation. So here are a few hopefully helpful facts: 1. The fact that something is in the base, or in the ports, has absolutely no bearing on whether one piece of software is fundamentally more useful or valuable than another. 2. burncd has only ever worked with a subset of the legacy ATA hardware. 3. ATA-CAM is on by default in FreeBSD 9 (which means that rather than acd0 as an ATA device you'll have cd0 as a SCSI device). 4. However, ATA-CAM is not mandatory, which means that leaving burncd in the base for those that want to continue using the legacy ATA interface is a perfectly reasonable course of action. 5. For those that wish to use the default ATA-CAM interface the cdrecord port provides a mature, full-featured solution. Even if it were possible to import it into the base, doing so would be a step in the wrong direction. > You do not knowingly leave a non-working utility in the system, period, That makes sense, however see above. > or not provide a included replacement for a popular utility as this one. The alternative already exists. The fact that it's not in the base has no relevance. I hope this clears up your confusion. If you have any further questions please direct them to freebsd-questions@FreeBSD.org only. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
ead...@freebsd.org wrote: Synopsis: 9.0 burncd error caused by change to cd0 from acd0 State-Changed-From-To: open->analyzed State-Changed-By: eadler State-Changed-When: Mon Sep 26 23:24:00 UTC 2011 State-Changed-Why: requires only a release notes entry; use cdrecord instead of burncd http://www.freebsd.org/cgi/query-pr.cgi?pr=160979 Your solution is very un-professional. What your solution purposes to do is do nothing. I think your judgment is flawed and a larger group of your peers need to review your judgment in this case. burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. You do not knowingly leave a non-working utility in the system, period, or not provide a included replacement for a popular utility as this one. The alternative is to fix burncd or backout the acd0 to cd0 change from 9.0 which may be the most desired solution because its obvious that no one researched the impact this change may have. This change may impact many ports that access cd/dvd drives for read and write access. burncd may be a very small worm in a large can of big worms. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
