From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 13 12:33:08 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D34616A420; Mon, 13 Feb 2006 12:33:08 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E8A043D72; Mon, 13 Feb 2006 12:32:58 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from [194.192.25.142] (spider.deepcore.dk [194.192.25.142]) by spider.deepcore.dk (8.13.4/8.13.4) with ESMTP id k1DCWp86004624; Mon, 13 Feb 2006 13:32:51 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <43F07C73.6040502@deepcore.dk> Date: Mon, 13 Feb 2006 13:32:51 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 1.5 (X11/20060130) MIME-Version: 1.0 To: Chiharu Shibata References: <20060213121101.47A5AA98F@m-kg282p.ocn.ne.jp> In-Reply-To: <20060213121101.47A5AA98F@m-kg282p.ocn.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: freebsd-hackers@FreeBSD.ORG, re@FreeBSD.ORG, nork@FreeBSD.ORG, core@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: kern/60163 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 12:33:08 -0000 Chiharu Shibata wrote: > At Sun, 12 Feb 2006 17:02:37 JST, you wrote... > >>> To mount this DISC, your opinion is... >>> (1) at first, try "cdcontrol -f /dev/acd0c info" to make sure where >>> track is data area. >>> (2) type "mount_cd9660 -o rdonly /dev/acd0t13 /cdrom". >>> Is this right? >> Yeah that used to work at least, if not it needs fixing of course.. > > Hmm, succeeded under your environment... > >> Any chance you could put up a mirror of that disk image so I could burn >> me one exactly like it to test with please ? the one I had here of the >> sort seems to have gone amiss, making testing a pain.. > > My sample DISC is a commercial product. The copy is forbidden, of course. > However, about this problem, We may consider that it is not peculiar to > this product. > When I wrote that patch at first, some testers used another DISC, and > some result as me with/without patch. Well, without proper samples it'll be hard to work on this, if this is as common as suggested finding free samples that I can use for testing should not be a problem ? > > A various situation, my environment does not change/update-to-current. > So I will collect testers again and have it investigated whether it can > mount via /dev/acdNtY or not. > If it can, I will withdraw about "1st Problem". > > But "2nd/3rd Problem" remains as before, I want to ask your opinion > about these. > Moreover, the point that beforehand investigation of which track is > data area, this is very unreasonable restriction, I think. Hmm, could it be that the data track is always the last track ? You cannot compare SCSI/ATAPI behavior here, since the SCSI layer cannot handle ! %512 byte sectors it doesn't have to handle audio tracks. Native ATA/ATAPI on the other hand supports *any* sector size and needs to set the right sector size for each track. Now if you need a specific track you need to access that one via the acdNtY interface to gt the sector size right, if that fails I'll fix it :) Oh, and yes I'm talking 6.x and -current here, anything before that I don't support due to lack of spare time.... -Søren