[PATCH RFC 0/3] add fc transport events

[PATCH RFC 0/3] add fc transport events

[Mike Christie]

The following patches begin to address the problem of allowing
a userspace program to online or offline a scsi device. The major
change is the layout of the transport class so that devices are
presented under an adapter with the fc_transport class node the root
for adapters. There's still no adapter level attributes so the host's
class_device is really just being used as way to nicely structure things,
and the class_device in the scsi_device has been converted to a kobject.


Here is a partial tree:

elm3a38:/sys/class/fc_transport # tree
.
|-- host4
|   |-- 4:0:0:0
|   |   |-- node_name
|   |   |-- port_id
|   |   `-- port_name
|   |-- 4:0:1:0
|   |   |-- node_name
|   |   |-- port_id
|   |   `-- port_name
|   `-- device -> ../../../devices/pci0000:02/0000:02:03.0/host4
`-- host5
     |-- 5:0:0:0
     |   |-- node_name
     |   |-- port_id
     |   `-- port_name
     |-- 5:0:1:0
.
.
.

01-add-host-transport-classdev.patch - adds the transport class_device to
the scsi_host structure.

02-sdev-transport-kobj.patch - converts the transport class_device in the
scsi_device to a kobject.

03-convert-fc-class.patch - converts the fc class from a class_device
scsi_device to a kobject and adds a basic link_up/down event fucntion.

(I did not convert the spi class yet, becuase I wasn't sure how people
would feel about such a change)

Mike Christie

Re: [PATCH RFC 0/3] add fc transport events

[Martin Peschke3]

> 03-convert-fc-class.patch - converts the fc class from a class_device
> scsi_device to a kobject and adds a basic link_up/down event fucntion.
>
> (I did not convert the spi class yet, becuase I wasn't sure how people
> would feel about such a change)

Looks promising as to FC. We can add these calls in the zfcp lldd
provided the patch makes it into the kernel. Then, what would be still
missing are the required hotplug scripts, I guess.

Martin

Re: [PATCH RFC 0/3] add fc transport events

[Mike Christie]

Martin Peschke3 wrote:
> 
> 
> 
>>03-convert-fc-class.patch - converts the fc class from a class_device
>>scsi_device to a kobject and adds a basic link_up/down event fucntion.
>>
>>(I did not convert the spi class yet, becuase I wasn't sure how people
>>would feel about such a change)
> 
> 
> Looks promising as to FC. We can add these calls in the zfcp lldd
> provided the patch makes it into the kernel. Then, what would be still
> missing are the required hotplug scripts, I guess.

There are still some other large outstanding issues. For example the
kobject_hotplug function must be called from a process context. I was not
sure if the transport class should provide this, or is it the drivers
responsibilty (some drivers have threads for work already),
or should SCSI ML supply this as it may have to if it is going
to provide events too.

> Martin
> 

Re: [PATCH RFC 0/3] add fc transport events

[Martin Peschke3]

> There are still some other large outstanding issues. For example the
> kobject_hotplug function must be called from a process context. I was not
> sure if the transport class should provide this, or is it the drivers
> responsibilty (some drivers have threads for work already),
> or should SCSI ML supply this as it may have to if it is going
> to provide events too.

The zfcp lldd also deploys threads to do link recovery. But I am not sure
whether the event
notifications we have been discussing would always fit into it. Other
lldd's might have no
threads at all. I tend to say that the midlayer should make sure that the
actual hotplug
calls are done in the right context in order to avoid duplicate pain in
various lldds.
Is there really no existing way to notify hotplug in a non-process context,
i.e. to have
hotplug schedule the actual work asynchronously?

Martin

Re: [PATCH RFC 0/3] add fc transport events

[Mike Christie]

Martin Peschke3 wrote:
> 
> 
> 
>>There are still some other large outstanding issues. For example the
>>kobject_hotplug function must be called from a process context. I was not
>>sure if the transport class should provide this, or is it the drivers
>>responsibilty (some drivers have threads for work already),
>>or should SCSI ML supply this as it may have to if it is going
>>to provide events too.
> 
> 
> The zfcp lldd also deploys threads to do link recovery. But I am not sure
> whether the event
> notifications we have been discussing would always fit into it. Other
> lldd's might have no
> threads at all. I tend to say that the midlayer should make sure that the
> actual hotplug
> calls are done in the right context in order to avoid duplicate pain in
> various lldds.

I will post my patch to handle this with a SCSI-ML workqueue. All transports
and SCSI-ML can then send an event without worrying about process context.