All the heavy-duty codes I have seen that perform I/O use open not
fopen.
I contend that for the kind of applications that MPI-IO is intended
for, it will not be good enough to say nothing about file permissions
in MPI_Open. (Though it is tempting to say nothing, and therefore
nothing has been said so far.)
> I don't understand the suggestion that there be
> a POSIX-like permission as an argument to MPI_Open,
> with the possibility of putting fancier things in
> the info argument. What advantage does this have
> over putting permissions in the info argument?
> I assert there is none. There is no portability
> advantage; There is no functional advantage;
> there is no semantic advantage. Having an argument other
> than info which is implementation-dependent and is
> routinely ignored or overriden seems like a bad idea.
Although it is true that MPI-IO is not intended only for a Posix-like
environment, it is also true that a vast majority of potential MPI-IO
customers currently use a Unix-like API. For them to accept MPI-IO,
the transition from a Unix-like API to MPI-IO must be as
painless as possible. For this we have taken specific steps so far:
1. Simplified MPI_Open so that it resembles Unix open
2. Separated the view from open. The default view is just
bytes--identical to an open Unix file. So a user need not even call
MPI_View if he doesn't want to.
3. Made hints/info entirely optional. A novice need not even use
them.
4. Renamed the original MPI-IO read/write calls so that MPI_Read now
uses the individual file pointer like Unix read. The explicit
offset calls are now called MPI_Read_explicit ...
Supporting Posix-like int perm in MPI_Open and anything funkier in
info may not be aesthetically appealing, but makes sense from a
practical standpoint. It does not destroy portability; instead, makes
it easier for the Unix users and at the same time supports other file
permission styles as well. I am just trying to put myself in the shoes
of real users and see what they would want, and at the same time also
support the power users.
Rajeev