[Stgt-devel] [PATCH] add stgt_device_template example

[FUJITA Tomonori]

From: Mike Christie <michaelc at cs.wisc.edu>
Subject: Re: [Stgt-devel] [PATCH] add stgt_device_template example
Date: Wed, 07 Sep 2005 20:32:05 -0500

> >>>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.

I expected you not to fancy this :)


> > 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)

That sounds a right solution.

conn_create/destroy and set/get_param can be handled by protocol
modules. And there is some target driver specific stuff, I guess.


> 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).

I see. In user-space, we have target driver libraries (dynamic
libraries, as Christoph suggested before), protocol specific stuff,
and stgtd core. We need to handle all cleanly.