From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [PATCH v8 10/11] scsi: sr: support (un)block events Date: Tue, 30 Oct 2012 08:34:29 +0400 Message-ID: <1351571669.3051.18.camel@dabdike> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:57263 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751269Ab2J3Eef (ORCPT ); Tue, 30 Oct 2012 00:34:35 -0400 In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Alan Stern Cc: Aaron Lu , Jeff Garzik , "Rafael J. Wysocki" , Tejun Heo , Oliver Neukum , Jeff Wu , Aaron Lu , Shane Huang , linux-ide@vger.kernel.org, linux-pm@vger.kernel.org, linux-scsi@vger.kernel.org, linux-acpi@vger.kernel.org On Mon, 2012-10-29 at 18:22 -0400, Alan Stern wrote: > On Mon, 29 Oct 2012, James Bottomley wrote: > > > On Mon, 2012-10-29 at 17:01 +0800, Aaron Lu wrote: > > > 2 interfaces are added to block/unblock events for the disk sr manages. > > > This is used by SATA ZPODD, when ODD is runtime powered off, the events > > > poll is no longer needed so better be blocked. And once powered on, > > > events poll will be unblocked. > > > > > > These 2 interfaces are needed here because SATA layer does not have > > > access to the gendisk structure sr manages. > > > > I'm afraid this is a nasty layering violation. You can't have a low > > level driver have knowledge of a call back in an upper layer one (in > > this case sr_block_events). > > > > This is all done it looks like because of the problem of getting access > > to the scsi_cd structure from libata, but it's not the right way to > > solve it. > > > > I also don't really think you need to do any blocking or unblocking. As > > I said in the previous thread, just fake the events the standard tells > > you to, so userspace can probe to its heart's content and you can keep > > the device powered off. > > James, one of us has misunderstood the event-polling mechanism. As far > as I know, the polling calls that Aaron is concerned with are generated > by the kernel, not by userspace. I don't think the origin of the poll changes anything in what I said above, does it? James