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

[Mike Christie <mikenc@us.ibm.com>]

James Bottomley wrote:

> On Sun, 2004-06-13 at 16:44, Mike Christie wrote:
> 
>>I am not adding a host and a device transport class. I am structuring 
>>things so there is a single fc transport class.
> 
> 
> I don't think that's such a good idea.  A class is supposed to represent
> an interface on a device.

Ok. I saw the class as representing a "thingy" not necessarily a device, 
becuase at one point the mainatiner had taken out the coupling of the 
"struct device" to the class_device which I thought this was for. For 
example the io scheduler or request queue could and probably should be a 
class if you wanted to abe able to hot swap the schedluer. In my case I 
was representing the transport itself as a class (the class_device 
should have gone into the fc_transport object and a transport_kobject 
should have been placed into the host though).

   The host and scsi device should have separate
> interfaces.  The only reason we don't have any host interfaces in the
> transport classes is because no-one has yet had a reason to add one. 
> However, since the loop status is definitely a host property, you
> do...part of what's missing is an attribute showing the loop state.  SPI
> has a similar need; the host property there is LVD or SE, and we might
> be interested in transitions between them.
> 
> 
>>The kobject I added to the scsi_device replaced the class_device (and 
>>its kobject) we were previously using for the device oriented transport 
>>class. I did this only because I wanted the scsi device's parent to be 
>>the host. In my patch, I then added a class_device to the host becuase 
>>the host's parent was the "FC Class".
>>
>>There is no technical argument why they couldn't be coded the way you 
>>described. My patch just has the FC Class, where under it the device, 
>>host and whatever objects arise are set up as parent/children to reflect 
>>how SCSI/FC and the kernel structures really were.
>>
>>It does not make a difference to me. It is easier to code just having a 
>>fc_host_transport_class and a fc_device_transport_class. It seemed like 
>>a waste to add more classes and doing the symlinks when you can just 
>>restructure things though.
> 
> 
> Well do it as two separate classes then.  Kobjects and Ksets are a bit
> of a minefield that I'd rather we didn't get into unless it's really,
> really necessary.  The abstraction we care about is the interface, which
> to the generic device stuff is the class.  If we stick to what we need,
> we'll get broken by generic device changes less often...
> 

Ok then.

Will this mean we will end up with device and host specific error 
handler issues that the classes will have to coordinate? For example, if 
I got a link down I know that cmds are going to be timing out for every 
device on the host, but depending on the setup if just the device's port 
went down I will not get a link down and may want to do something 
different. Or maybe not?

Mike