On Sep 15, 2007, at 9:56 AM, Julian Martin Kunkel wrote:
Hi Sam,
cool that you made the modifications ;-)
I think the overall changes look good. There are only a few (minor)
comments
you might consider if you like..
I would rather avoid to store the encode & decode functions
explicitly in the
PVFS_hint_s struct, because it is contained in the PINT_hint_info
struct as
well. I add some comments and modifications directly to the structure:
Agreed. I'll make that change.
typedef struct PVFS_hint_s
{
struct PINT_hint_info * type; /* link with the specific type */
char* unknown_type_name; /* used only if the type is unknown
otherwise the
* name is available in the
type array*/
char* value;
int32_t length;
int flags;
struct PVFS_hint_s *next;
/* int count; where and how do you use this value ? */
Its probably just left-over from wanting to keep track of
transferrable hints instead of having to compute the number at encode
time. I can remove it.
} PINT_hint;
Therefore just add a dummy type for unknown hints in the
PINT_hint_info struct
to cover for the encode functions:
static const struct PINT_hint_info hint_types[] = {
{PINT_HINT_UNKNOWN
PINT_HINT_TRANSFER,
PVFS_HINT_UNKNOWN,
encode_func_string,
decode_func_string,
0, /* value gets automatically filled depending on the length
of the hint
*/
...
}
Maybe it would be neat to have another function:
int PVFS_hint_add_internal(
PVFS_hint *hint,
int type, /*instead of string */
int length,
void *value)
That one could be used internally for instance as follows:
In the function decode_PINT_hint the function PVFS_hint_add is
used. I like
this idea to support unknown hints (from the clients view) to work
on servers
understanding the hint. However, for known hints this extra
computation could
be avoided by using the available hint type directly. This would
avoid to
look up the hint's type by the server again.
Yep, that's fine. I'll add that.
-sam
Also if the server might want to add a hint directly (for further
inter server
communication) it could do so by using the PVFS_hint_add_internal
function
itself. (I used something like this to tag special migration I/O's
between
the servers)...
With your scheme (with or without the modifications I propose)
adding new
hints seems unproblematic. If the server does not understand the
hint it is
ignored, the client encodes it as a string. A problem is only if
the client
has a different order of the hints as the server.
That is fine with me ;-)
Best regards,
Julian
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
