Date: Fri, 16 Nov 2007 10:54:21 -0700 From: Scott Long <scottl@samsco.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@deepcore.dk>, Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/dev/ata atapi-cd.c atapi-cd.h Message-ID: <473DD94D.8050605@samsco.org> In-Reply-To: <29576.1195233852@critter.freebsd.dk> References: <29576.1195233852@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > In message <473DCF61.6010107@samsco.org>, Scott Long writes: > >>> What I've sortof talked phk into is that if I return the "right" error >>> code in the "start" function, it will back off and not retry nor chatter. >>> We still need the "access" function to return OK if HW present or we >>> cannot send ioctl calls to an empty drive. >>> >> IMHO, overloading g_start just adds more cruft to the problem. > > The fundamental problem is that the CDROM ioctls don't distinguish > between drive and media. > > In a nutshell: we are forced to let the open succeed, so the ioctl > to close the tray can be issued, before we can get at the media. > > The problem with letting the open (aka g_access) succeed, is that > the GEOM tasting starts. > > Redefining the ioctls is not a realistic option at this point, so > the task is to find a workaround for the API-deficiency. > > What sos@ and I talked about is that we need to have an error return > that says "The drive is here, but there is no media", to fail the > tasting without GEOM reporting I/O errors on the console. > > The simplest way to do this, is probably to overload ENOENT or some > other currently undefined errno for this effect. > But then why not have g_access be able to communicate the ability to access the device independent from the ability to access the media? Seems like both of these questions are "access" questions. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?473DD94D.8050605>