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