>> 1) Since the perm parameter is not a hint, the semantics are
>> that implementations are guaranteed to honor it.
>>
>> In some environments, this matters.
>
>There may be some confusion here over info arguments. My understanding
>of info arguments comes from their use in the dynamic chapter. It it's
>wrong, we need to reconcile dynamic and io. The way they are used
>in dynamic is that MPI reserves the key and any implementation
>that recognizes the key must implement it exactly as defined by
>MPI. In that sense implementations are "guaranteed to honor
>it". I assume that even in the perm argument proposal,
>an implementation is allowed to ignore argument, right? Otherwise
>you could not have an MPI implementation in a non-posix environment.
There is an important distinction here. Under the proposal to add
an unsigned int perm parameter, an MPI_Open() that returns with a
success *is* guaranteed to have supported the requested permissions
for the perm flag. Implementations without the ability to provide
POSIX compliance would require that the special MPI_PERM_NULL
or the MPI_PERM_IN_INFO flag be used. If a non-POSIX implementation
unable to support the perm value is not given MPI_PERM_NULL or
MPI_PERM_IN_INFO, the MPI_Open() should not be successful.
I believe some would find it highly undersirable if a valid MPI
implementation can return a success for an MPI_Open() and the requested
permissions are not imposed. Under the proposal, a correct program
(which checks for success) has a guaranteed behavior regardless of where
it is moved. I don't have to know the specifics of whether my permission
request was ignored or not because the permission request is intrinsic
with the open, not a hint.
Perhaps this subtle point should be made more clear in the text?
>> 2) Since the vast majority of implementations will likely be
>> in environments with a POSIX-like interface (at least in the
>> near term), it provides a familiar and easy to use interface
>> for the common case.
>>
>> Ease of use is also important.
>
>Two comments on the ease of use argument. One is that in the short
>term the POSIX interface may be likely, but I hope that in the long
>term something more robust (like AFS or DFS ACLs) becomes common.
>My experience, which may be different from yours, is that I have
>never seen a scientific program that opened opened a file with
>specific permissions. Of course most of the programs we have around
>here are Fortran (possibly also the most commonly used language
>for MPI programs) and setting permissions isn't an option.
>I am hard pressed to think of an example where a umask wouldn't
>be sufficient - i.e., where you'd want to create different files
>with different permissions - at least in the realm of scientific
>programming. Of course MPI isn't only for scientific computing...
>For the following motivation:
>> For example, the following program on my Sun
>> workstation does not create a file with the permissions that
>> correspond to my umask. It creates something entirely different;
>> doesn't even give me read permission.
>This can be considered a quality of implementation issue. Perhaps
>an advice to implementors that MPI_Open should not ignore the umask?
>And of course I fully support a reserved info key.
I don't quite know what to say about this -- everyone's experience
is different. I do believe that many will find this familiar and
easy to use.