Re: [PATCH] fc transport: Add support for events

[James Smart <James.Smart@Emulex.Com>]

It would have been nice to have had this response on the RFC.

I'm actually looking into netlink for the CT pass thru, ELS and rnid
functions.

Does it make sense to move forward with some event support - namely
the events attributes minus the kobject_uevent() stuff ?

-- james

Christoph Hellwig wrote:
> 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..