From owner-freebsd-current@FreeBSD.ORG Tue Sep 27 04:10:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84AEE106564A; Tue, 27 Sep 2011 04:10:18 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01E2A8FC15; Tue, 27 Sep 2011 04:10:17 +0000 (UTC) Received: by yxk36 with SMTP id 36so6250710yxk.13 for ; Mon, 26 Sep 2011 21:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=k5+Yp8ucyzfdzMITUlLRHaEc4AvwAUy70DhUjyzA4SQ=; b=pVJG1NQJ+fdk0Ryah2vW8bt52OXzWIf7jJrwfw0knbDLiMeEh8qlz1+DEd0EJLjOJn d7KR7qGN0HUmwTx0yxHj6bbuLI4LgFTfRUdFpRrCD0Tueu42ssbpRe/vxymZpp0cU5S4 ZmSM4ACAAt/N+QtKQ/5wL5NISWeynlEsxOLIo= Received: by 10.236.183.131 with SMTP id q3mr1221446yhm.58.1317096617180; Mon, 26 Sep 2011 21:10:17 -0700 (PDT) Received: from c-24-6-49-154.hsd1.ca.comcast.net (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id p68sm32037630yhj.16.2011.09.26.21.10.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 21:10:16 -0700 (PDT) Date: Mon, 26 Sep 2011 21:10:13 -0700 (PDT) From: Garrett Cooper To: Craig Rodrigues In-Reply-To: Message-ID: References: <201109262324.p8QNO0NN070853@freefall.freebsd.org> <4E811FF7.7010607@a1poweruser.com> <4E8126D3.5020407@FreeBSD.org> <4E812DB7.3000302@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="967339439-653406307-1317096616=:81576" Cc: Doug Barton , eadler@freebsd.org, Garrett Cooper , Fbsd8 , freebsd-current@freebsd.org, FreeBSD Questions Subject: Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 04:10:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --967339439-653406307-1317096616=:81576 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT 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 --967339439-653406307-1317096616=:81576--