[Stgt-devel] [PATCH] add stgt_device_template example

Mike Christie michaelc at cs.wisc.edu
Tue Aug 23 19:29:22 CEST 2005


FUJITA Tomonori wrote:
> From: Mike Christie <michaelc at cs.wisc.edu>
> Subject: Re: [Stgt-devel] [PATCH] add stgt_device_template example
> Date: Tue, 23 Aug 2005 11:05:54 -0500
> 
> 
>>>Do we need to use GFP_ATOMIC instead of GFP_KERNEL in
>>>stgt_device_create()?
>>
>>I do not think so. It does not seem like we will be in
>>interrupt context and it does not look like we
>>are under a spin_lock. Was there something else
>>you were thinking of (probably was :))?
> 
> 
> I thought that possibly we are in interrupt context, though as far as
> I know, no HBA drivers do it.

yeah from looking at the qlogic code from SCST it looks like SCST is 
implemented as a SCSI ULD - kinda. It implements a driver model 
class_interface so its dev_handlers will get their attach() called from 
the class_interface add() call and that is coming from when scsi_devices 
are added to scsi-ml (like how sg works I guess).

I was thinking we were going to have userspace call into stg_core to add 
devices (similar to how iet's ioctl called into it to add volumes). The 
stgt_device code would eventually replace iet's volume code. I was 
replacing IET's ioctl and hit the volume and target ioctls so that it is 
why patches showed up the same time you asked about it :)

But by keeping more in userspace like IET does and not doing a 
class_interface for scsi_devices like SCST, we do not have to worry 
about the scsi refcouting and scsi_device state stuff SCST messed up on 
becuase they dug so deep in there.



More information about the stgt mailing list