Bart Van Assche wrote:
> On Wed, Feb 17, 2010 at 11:29 PM, Joe Eykholt <[email protected]
> <mailto:[email protected]>> wrote:
>
> Vladislav Bolkhovitin wrote:
> > Joe Eykholt, on 02/13/2010 01:30 AM wrote:
>
> >> fcst keeps track of read/write progress in its own ft_cmd struct
> for now.
> >> Is there a standard way of doing that via scst_cmd? If not,
> that'd be
> >> nice.
> >
> > I'm not sure what you mean. Basically, a target driver doesn't
> need to
> > keep track of progress of any commands, it simply should on each
> event
> > from SCST or hardware call the next function to switch to the
> next state
> > of the processing state machine. On each state there is only one such
> > function.
> >
> > The only area where there's a need to know commands processing
> states is
> > errors recovery, when you inside driver need to figure out how to
> abort
> > a command. For instance, it might be needed in
> > on_hw_pending_cmd_timeout() callback.
>
> What I meant here, is when I'm receiving data or sending data, I need
> a way of keeping track of how much has been received or sent, so I know
> when its done, and whether any has been missed. I can require that
> it be received in sequence, and will always send sequentially, of
> course.
>
> It seems like other target drivers would need that, too. Is there
> a common way to do that?
>
>
> As far as I know the block layer in the Linux kernel uses a radix tree
> to solve a similar issue: to keep track of which data has already been
> read and which not. See also:
> * http://lwn.net/Articles/175432/
> *
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=include/linux;hb=HEAD
> *
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=mm/readahead.c;hb=HEAD
Thanks for those links, Bart. It's good to know about that infrastructure.
fcst doesn't need anything that complicated, just a count of bytes
received and successfully sent. There are a few other things
for fcst to keep track of anyway, so it is OK that it needs its own
cmd struct for now.
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
