Ang: Re: [Stgt-devel] [PATCH] add stgt_device_template example

johan at johan at
Mon Sep 12 16:04:11 CEST 2005


 I´m new to this list, but has been in the IET since the beginning. Where
can I read something about the ideas behind this project? Is the idea to
become a midlevel scsi target driver, that handles ALL the scsi specific
commands, to be used of ANY target driver that uses scsi commands, like Fc
or iScsi? If so, I would give my full support for it.

               Best regards from/Med vänliga hälsningar från

                                 Johan Kragsterman


                    FUJITA Tomonori                                                                                       
                    <fujita.tomonori at lab.       Till:   michaelc at                                              
          >                  Kopia:  stgt-devel at                                       
                    Sänt av:                    Ärende: Re: [Stgt-devel] [PATCH] add stgt_device_template example         
                    stgt-devel-admin at berl                                                                                 
                    2005-09-12 16:12                                                                                      

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

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

Mike, can you tell me the details of your design (or commit the
initial code)? I don't get a clear idea of how this part should be
implemented yet.
Stgt-devel mailing list
Stgt-devel at

More information about the stgt mailing list