From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 07:07:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2D8616A4CE for ; Fri, 15 Oct 2004 07:07:28 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D99543D45 for ; Fri, 15 Oct 2004 07:07:28 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1CIMBL-0000Ol-BA; Fri, 15 Oct 2004 11:07:19 +0400 From: Vladimir Grebenschikov To: Chuck Swiger In-Reply-To: <416EE19D.50400@mac.com> References: <20041013205141.GA874@galgenberg.net> <20041014105927.GU718@empiric.icir.org><416EC5F4.8000203@mac.com> <416EDA36.1070403@DeepCore.dk> <416EE19D.50400@mac.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Fri, 15 Oct 2004 11:07:18 +0400 Message-Id: <1097824038.1049.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: freebsd-current@freebsd.org cc: =?ISO-8859-1?Q?S=F8ren?= Schmidt Subject: Re: atapicam(4) as KLD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2004 07:07:29 -0000 =D0=92 =D1=87=D1=82, 14/10/2004 =D0=B2 16:29 -0400, Chuck Swiger =D0=BF=D0= =B8=D1=88=D0=B5=D1=82: > S=C3=B8ren Schmidt wrote: > > Chuck Swiger wrote: > >> Michael Nottebrock wrote: > >>> Easy workaround: Put atapicam into GENERIC. I'm waiting for that to=20 > >>> happen ever since atapicam entered the tree. > >> > >> I'd strongly agree, unless there is a major downside to doing so. > >> > >> (Disclaimer: Having ATAPICAM in GENERIC would reduce my email support=20 > >> burden for the dvd+rw-tools port by a noticable fraction. :-) > >=20 > > But will do the opposite to my mailbox, and I *dont* support atapicam,=20 > > so I think its a bad idea, besides I waste enough time as is, thanks... >=20 > My comment about email support was intended to be humorous. If I didn't = want=20 > to provide technical support to other people, I probably wouldn't spend a= s=20 > much time as I do answering people's questions, on list and off. >=20 > Be that as it may, Soren, I guess you're free to not welcome questions ab= out=20 > atapicam. Would having it in GENERIC would make much difference to you i= f=20 > other people are willing to answer any questions which get asked on the=20 > mailing lists about it...? >=20 > Is burncd able to burn a DVD [+/-{R,W,RAM}] to an IDE device without usin= g=20 > ATAPICAM? I think it is not unreasonable to expect the GENERIC kernel to= be=20 > able to burn DVDs, as that can make for a reasonable backup mechanism. well, just format and burn DVD+RW with burncd - no problems, but frankly speaking, I do not like idea to have two devices for each drive, like : acd0: CDROM at ata1-master UDMA33 acd1: CDRW at ata1-slave UDMA33 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ata1 bus 0 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device=20 cd1: 33.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present % ls /dev/*cd* /dev/acd0 /dev/acd1 /dev/cd0 /dev/cd1 % It can mislead people. What happens if one will do both burncd on /dev/acd0 and cdrecord on /dev/cd0 at same time ? Atapi-cam strange add-on it should be basic mapping (no adX/acdX) or no mapping at all (only atX/acdX). I like idea to see all direct access drives from user-land with same interface (like USB, SCSI, FireWire drives all seen as daX or cdX/passX) > [ Peripheral note: DVDs are OK for backup, that is, but I much prefer tap= es=20 > for durability and long term storage. Quantum sDLT 220 drives rock. ] --=20 Vladimir B. Grebenchikov vova@fbsd.ru