[Stgt-devel] [PATCH] add stgt_device_template example
fujita.tomonori at lab.ntt.co.jp
Thu Sep 8 03:59:36 CEST 2005
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.
More information about the stgt