On Wed, Feb 22, 2006 at 11:09:24AM -0500, James Smart wrote: > > The following patch adds support for hbaapi events within the FC transport. > It adds the following attributes to the fc_host: > max_events : sizes the internal array for the number of events that are > buffered in the transport. This value can be tuned by a > module parameter. > event_cnt : number of events pending in the buffer > event : reads an event from the buffer > > It adds the following routine for LLDD's to post events: > void fc_host_event_post(struct Scsi_Host *shost, > enum fc_host_event_code event_code, u32 event_data); > > Not all hbaapi events are contained within the transport. Many events > correspond to elements outside the fc_host, and can be serviced by normal > hot-plug events, either on the fc_host, or rport. I believe I've included > those events that could be posted. I've also punted on anything that has > more > than 1 32-bit word of data - which should only affect RLIR payloads, and > vendor-unique payloads. We will address these items once we figure out how > to deal with large payloads in the transport. > > In conjunction with the event infrastructure, the module uses hot plug > events > to notify user entities about changes. For the fc_host, the only event > posted > is a KOBJ_CHANGE event. For the rport, ONLINE/OFFLINE is posted whenever > the > rport goes through a block, then unblock. To get to the class_device for > the > rport, a new attribute_container function is added locate the class_device > for > the device. > > This implementation expects the user-space hbaapi provider to deal with > multiple user-space readers. > > I've coordinated with Andrew Vasquez, who has sent his approval. > > The lpfc driver will be posted shortly to utilize this infrastructure. I must admit I don't like this too much. The natural way to send events to userspace would be a netlink socket, but integrating this with the transport class might be a bit hard. Having named netlink sockets similar to named unix sockets would be nice for this.. - : 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
