[Pvfs2-developers] a little help?

Murali Vilayannur murali.vilayannur at gmail.com
Wed Oct 25 15:18:45 EDT 2006


hi Walt,
Sorry for not explaining clearly. After the PVFS_isys_*() call completes
immediately, we need to copy the results from the system
responses to the kernel by writing it to the device file.
The ->was_handled_inline member variable is actually set in
write_inlined_device_response() which also does the kernel copy internally.
So what I meant to say was..

Uh, what?  what do you mean by "copy the results to the downcall"?
> Your post indicated that if the was_handled_inline member was set that
> was all that was needed.  Is something else needed?  I don't know what a
> downcall is or how to copy results there.


switch(ret) {
case SM_ACTION_TERMINATE:
    vfs_request->out_downcall.type = vfs_request->in_upcall.type;
    vfs_request->out_downcall.status = XX; /* This should be set to the
return value of the isys_* call */
    write_inlined_device_response(vfs_request);
   /* Fall through */
case 0:
    if (vfs_request->was_handled_inline) {
       ret = repost_unexp_vfs_request(vfs_request, "..");
    }
....

perhaps that explained it a little better I hope,
thanks,
Murali

Walt
>
> Murali Vilayannur wrote:
> > Hi Walt,
> >
> >> Maybe it would be simpler to modify the code as shown:
> >>
> >> >>     /*
> >> >>       check if we need to repost the operation (in case of failure
> or
> >> >>       inlined handling/completion)
> >> >>     */
> >> >>     switch(ret)
> >> >>     {
> >>             case SM_ACTION_TERMINATE:
> >>                 vfs->request->was_handled_inline = 1;
> >
> >
> >
> >
> > Ok, that works too :)
> > Just remember to copy the results to the downcall (calling the
> > write_inlined_device_response should do the trick)
> > before reposting the op.
> > thanks,
> > Murali
> >
> >>                 /* this code falls through to the next case */
> >> >>         case 0:
> >> >>         {
> >> >>             /*
> >> >>               if we've already completed the operation, just repost
> >> >>               the unexp request
> >> >>             */
> >> >>             if (vfs_request->was_handled_inline)
> >> >>             {
> >> >>                 ret = repost_unexp_vfs_request(
> >> >>                     vfs_request, "inlined completion");
> >> >>             }
> >> >>             else
> >> >>             {
> >> >
> >> >
> >> > What we could do to retain this part of the code is to set the
> >> > ->was_handled_inline member variable in all the post_*_request()
> >> functions
> >> > if the PVFS_isys_*() function indicated that the posted operation
> >> finished
> >> > immediately.
> >> > If we do that, then we could retain this code as is without adding
> any
> >> > more cases. Great catch!
> >> > thanks,
> >> > Murali
> >> >
> >> >
> >> >>                 /*
> >> >>                   otherwise, we've just properly posted a
> non-blocking
> >> >>                   op; mark it as no longer a dev unexp msg and add
> it
> >> >>                   to the ops in progress table
> >> >>                 */
> >> >>                 vfs_request->is_dev_unexp = 0;
> >> >>                 ret = add_op_to_op_in_progress_table(vfs_request);
> >> >>#if 0
> >> >>                 assert(is_op_in_progress(vfs_request));
> >> >>#endif
> >> >>             }
> >> >>         }
> >> >>         break;
> >> >>         case REMOUNT_PENDING:
> >> >>             ret = repost_unexp_vfs_request(
> >> >>                 vfs_request, "mount pending");
> >> >>             break;
> >> >>         case OP_IN_PROGRESS:
> >> >>             ret = repost_unexp_vfs_request(
> >> >>                 vfs_request, "op already in progress");
> >> >>             break;
> >> >>         default:
> >> >>             PVFS_perror_gossip("Operation failed", ret);
> >> >>             ret = repost_unexp_vfs_request(
> >> >>                 vfs_request, "failure");
> >> >>             break;
> >> >>     }
> >> >>     return ret;
> >> >>}
>
> --
> Dr. Walter B. Ligon III
> Associate Professor
> ECE Department
> Clemson University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20061025/3e815ca0/attachment.htm


More information about the Pvfs2-developers mailing list