Current plans for SDEV_EVT_* and friends

Current plans for SDEV_EVT_* and friends

[Hannes Reinecke]

Hi Tejun,

seeing that you are moving the old SCSI / libata AEN handling over
to the new block-based workqueue, I was wondering what your plans
are with the remaining SDEV_EVT_* things.

Thing is I'm currently working on implementing proper Unit Attention
handling in the SCSI stack. For this I would need to have some field
off the scsi_device structure into which I can store information
about which events / event types are supported and which are activated.
So the existing bitmap approach with 'supported_events' would quite
a good starting point here, and it will even be useful to add
another one, eg 'enabled_events'.
And, of course, plan is to route appropriate events over to the
block workqueue by calling disk_check_events().

Unless you have other ideas/plans here ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Current plans for SDEV_EVT_* and friends

[Tejun Heo]

(cc'ing Kay)

Hello,

On Tue, Feb 01, 2011 at 03:55:14PM +0100, Hannes Reinecke wrote:
> seeing that you are moving the old SCSI / libata AEN handling over
> to the new block-based workqueue, I was wondering what your plans
> are with the remaining SDEV_EVT_* things.

SDEV_EVT_* are basically dead.  There's no valid user for it in the
kernel.  libata-scsi hasn't been converted yet - virtually SATA AN is
pretty much stillborn and converting it would require a way to map ATA
device to block device which isn't easy without changing SCSI.

> Thing is I'm currently working on implementing proper Unit Attention
> handling in the SCSI stack. For this I would need to have some field
> off the scsi_device structure into which I can store information
> about which events / event types are supported and which are activated.
> So the existing bitmap approach with 'supported_events' would quite
> a good starting point here, and it will even be useful to add
> another one, eg 'enabled_events'.
> And, of course, plan is to route appropriate events over to the
> block workqueue by calling disk_check_events().
> 
> Unless you have other ideas/plans here ...

So, I think using the block layer DISK_EVENT_* would be the right way
to do it, but what kind of events do you have on mind?

-- 
tejun

Re: Current plans for SDEV_EVT_* and friends

[Hannes Reinecke]

On 02/01/2011 03:59 PM, Tejun Heo wrote:
> (cc'ing Kay)
> 
> Hello,
> 
> On Tue, Feb 01, 2011 at 03:55:14PM +0100, Hannes Reinecke wrote:
>> seeing that you are moving the old SCSI / libata AEN handling over
>> to the new block-based workqueue, I was wondering what your plans
>> are with the remaining SDEV_EVT_* things.
> 
> SDEV_EVT_* are basically dead.  There's no valid user for it in the
> kernel.  libata-scsi hasn't been converted yet - virtually SATA AN is
> pretty much stillborn and converting it would require a way to map ATA
> device to block device which isn't easy without changing SCSI.
> 
>> Thing is I'm currently working on implementing proper Unit Attention
>> handling in the SCSI stack. For this I would need to have some field
>> off the scsi_device structure into which I can store information
>> about which events / event types are supported and which are activated.
>> So the existing bitmap approach with 'supported_events' would quite
>> a good starting point here, and it will even be useful to add
>> another one, eg 'enabled_events'.
>> And, of course, plan is to route appropriate events over to the
>> block workqueue by calling disk_check_events().
>>
>> Unless you have other ideas/plans here ...
> 
> So, I think using the block layer DISK_EVENT_* would be the right way
> to do it, but what kind of events do you have on mind?
> 
Well, partially.

DISK_EVENT_* is of course the right way to got if we're dealing with
events which _can_ be mapped onto a gendisk.
However, not all SCSI LUNs do have this mapping (eg LUNs not
associated with any device driver) and not all events affect a
single LUN. Some classes of events actually relate to the entire
target, which would require us to call back into the SCSI host itself.
Case in point: REPORT LUN DATA CHANGED, for which we would need to
rescan the host.

So we basically have to have another set of events in the SCSI
layer, some of which map to the existing DISK_EVENT_*, and some don't.
Of course I can go ahead and create my own set of events, but that
would nearly amount to code duplication.
Hence the idea of re-using SDEV_EVT_*
Or I'll be renaming them to SDEV_EVENT_* to be in-line with your
DISK_EVENT_* thing and to avoid confusion with the previous
implementation.

Cheers,

Hannes

-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Current plans for SDEV_EVT_* and friends

[Tejun Heo]

On Tue, Feb 01, 2011 at 04:29:50PM +0100, Hannes Reinecke wrote:
> > So, I think using the block layer DISK_EVENT_* would be the right way
> > to do it, but what kind of events do you have on mind?
> > 
> Well, partially.
> 
> DISK_EVENT_* is of course the right way to got if we're dealing with
> events which _can_ be mapped onto a gendisk.
> However, not all SCSI LUNs do have this mapping (eg LUNs not
> associated with any device driver) and not all events affect a
> single LUN. Some classes of events actually relate to the entire
> target, which would require us to call back into the SCSI host itself.
> Case in point: REPORT LUN DATA CHANGED, for which we would need to
> rescan the host.
> 
> So we basically have to have another set of events in the SCSI
> layer, some of which map to the existing DISK_EVENT_*, and some don't.
> Of course I can go ahead and create my own set of events, but that
> would nearly amount to code duplication.
> Hence the idea of re-using SDEV_EVT_*
> Or I'll be renaming them to SDEV_EVENT_* to be in-line with your
> DISK_EVENT_* thing and to avoid confusion with the previous
> implementation.

Hmmm... I suppose it really depends on each event.  If the userland
can't make much use of it, there's no point in doing the plumbing.  I
think the best way to proceed would be listing what events are there
and which actions need to be taken.

Both SDEV_EVT_* and DISK_EVENT_* are primarily concerned about
exporting the events to userland so that udev (or something similar)
can take action accordingly.  If there are events which make sense
that way, it would probably be best to add new disk events; otherwise,
they probably best remain as SCSI internal events.

-- 
tejun