[EMAIL PROTECTED] wrote on Sat, 09 Feb 2008 15:59 -0600:
> I would do that if I could think of a way. Those functions have to access
> the request specific field in the request structure. delete for example
> needs to get at:
>
> req->u.delete.handle
>
> I couldn't come up with a generic function for doing that. I was tempted
> to move the fsid+handle to the common parts of the request, so that every
> request had those fields (for some they would just be NULL), but that would
> have been a much larger change, and a protocol change to boot.
>
> If I were able to assume that the fsid and handle were always the first two
> fields in the request (for the requests that operated on a handle), I could
> just operate on the req->u union (a poor man's polymorphism), but I don't
> know if that's an assumption/requirement we want to make (and would be
> another protocol change for the requests that don't have those as the first
> two).
>
> If we wanted to go down this path further, I would probably want to work up
> some sort of bindings generator that would do a lot of the manual labor for
> us.
Oh, I see. Missed that. Yeah, the unions are a real pain. Not
worth trying to fix that here too, I agree. Funny, there already is
a target_handle in the server structure which may store exactly the
individual u.delete.handle you are working hard to extract. Still,
not worth the change if there is any risk of bugs here.
I see now that PINT_server_req_get_object_ref() returns NULL handle
and fs_id when no get_object_ref method is defined. Which means at
least you don't need special methods for mgmt_event_mon, get_config,
noop, etc. If you want to excise those at least.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
