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@xxxxxxx +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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
