Re: [PATCH v8 10/11] scsi: sr: support (un)block events

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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