[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