Date: Fri, 16 Nov 2007 16:21:25 -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: <473E25F5.1090805@samsco.org> In-Reply-To: <33907.1195254953@critter.freebsd.dk> References: <33907.1195254953@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > In message <473E238D.4030800@samsco.org>, Scott Long writes: >> Poul-Henning Kamp wrote: > >>>> Well, there are two questions: media present (yes/no) and drive capable >>>> of telling if media present without just trying to read it (yes/no). >>> This risk reopening the old religious war if drivers should poll >>> their drives to be up to date on media existence. >> This has nothing to do with polling, you're just trotting out an >> irrelevant argument to divert attention. > > No, I merely pointed out that Nates worries had an obvious and widely > accepted solution, which unfortunately is religiously unacceptable > in certain parts of FreeBSD storage subsystems. > > For all I know, the problem sos@ has complained about has a solution > that just needs somebody to change the relevant few lines of code. > Ok, back on track. What you want to do is make g_access largely irrelevant, and have the _real_ access check done in g_start. Fine. Is there any reason at all to make g_access not return success from now on? And if so, is there any reason to even keep it around? This is what I'm arguing against; you're advocating a hack that works well enough for you and ignoring the larger architectural issue, which I think is important. But anyways. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?473E25F5.1090805>