On Oct 10, 2006, at 2:18 PM, Bradley W Settlemyer wrote:
Sam Lang wrote:
What are the benefits of those functions over something like:
PVFS_sys_dist_set_param(..., "io-server-mapping", &server_map);
I dislike the idea of adding interfaces that won't get much use,
esp if we already have a generic mechanism for doing the same.
-sam
Just so we're all clear on what was intended with that interface,
the idea is that distributions can overload the behaviour of the
underlying parameter setter.
The distribution _is_ the underlying parameter setter. In the case
of the simple stripe, if the strip-size wasn't provided with
setparam, its the simple-stripe code that chooses the default. The
user of the system interfaces can overload that default, but the rest
of the pvfs code doesn't know anything about it.
I don't want to go round and round with this, I'm just trying to keep
things as user friendly as possible. There's a clear design built
into distributions: they're opaque to everyone but the distribution
methods. If possible, I think it would be good to keep it that way
(just imagine how fun the request processing code would be if it
accessed distribution fields directly). As for the
PVFS_sys_dist_setparam call, the way we use it in our code today is
in setting the strip-size on the simple stripe distribution (from
outside the system interfaces). Setting a server list or number of
servers via that call doesn't seem like its much of a stretch.
For example, in the default provided functions, I checked the data
for overrun of the distribution data type, but it doesn't have any
support for an underfilled data type (for example, if an int is set
into an int64, that's probably going to lead to 32 bits of random
junk in the distribution parameter). But that will work fine
(though perhaps precariously) for the default simple-stripe
distribution.
Yeah static type checking is lost with the void *. but is it worth
adding rather specific interfaces to avoid that?
The varstrip guys provided a parameter setter that parsed some a
string format. So the current model is that each distribution
provides its own string format. I'm not sure whether that's really
the best approach or not.
I view the underlying storage of the parameters and the interfaces to
those parameters to be orthogonal. Storing them as strings probably
makes sense. Making the caller sprintf into a string to create them
doesn't (even if that's what's mpich does :-)).
-sam
Cheers,
brad
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
