[Stgt-devel] [PATCH] add stgt_device_template example

[Mike Christie]

FUJITA Tomonori wrote:
> From: FUJITA Tomonori <tomof at acm.org>
> Subject: Re: [Stgt-devel] [PATCH] add stgt_device_template example
> Date: Sun, 28 Aug 2005 00:49:44 +0900
> 
> 
>>>>Does stgt enable target drivers to call their own functions when
>>>>user-space requires such operations?
>>>
>>>I think we will need to move the stgt_target_template registration to 
>>>the target driver's module_init function. We can add some callbacks onto 
>>>it so stgt can call into the target driver. Maybe a create_target(), 
>>>set_param(), get_param(), destroy_target(), etc is needed. I think this 
>>>is what you are suggesting right?
>>
>>I think so. I simply thought about mechanisms like
>>stgt_device_template, however, I didn't have a clear idea. I'll
>>implement that after the cleanup.
> 
> 
> I've done target_create/destroy callbacks.
> 
> I'll try to see how to integrate target driver daemons to stgtd. For
> that, ietd daemon needs to do all kernel-user space communication
> through stgt netlink. Thus, we need to add some iSCSI specific
> callbacks (like conn_create/destroy). Is it OK? Or is implementing

I do not think we want to do that since we would have stgt_core doing 
lower level transport stuff and as we add many the callouts for them 
could get out of hand.

> more generic message and callback(like STGT_UEVENT_SEND_MESSAGE) for
> target driver specific tasks better?

Yeah, maybe a generic event like that. Where if stgt doe not know how to 
handle the event it passes it to the protocol or target driver or 
transport. Or maybe it can flow downwards. For what we have now:

STGT_UEVENT_SEND_MESSAGE->stgt (if not mine pass down) ->protocol (pass 
down if not mine) ->target_driver (fail if not my message)

I guess either way we need to add something on the event so we can 
figure out who the event is supposed to be for. I ran into similar 
troubles with passing things upwards (see the TODO I added to the 
usr/netlink.c this morning).