Current plans for SDEV_EVT_* and friends
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
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
(cc'ing Kay)
Hello,
Quoted 3 lines · Hannes Reinecke
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.
Quoted 11 lines
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_devicestructure 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 callingdisk_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?
Signature · 1 line
tejun
Quoted 24 lines · Tejun Heo
(cc'ing Kay)
Hello,
Quoted 3 lines · Hannes Reinecke
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.
Quoted 10 lines
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_devicestructure 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 callingdisk_check_events().
Quoted 5 lines
Quoted 1 line
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
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 14 lines · Hannes Reinecke
Quoted 3 lines
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.
Quoted 8 lines
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.
Signature · 1 line
tejun