[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