Rajeev Thakur wrote:
> I think this would be a big change though. For one, it would make the
> concept of etype redundant, because of which we would have to revisit
> many definitions.
> ...
> If accesses are restricted to multiples of filetype, then filetype
> effectively becomes the etype, or vice-versa. Or am I missing
> something?
In considering this change, we should ask two questions:
1. Is this a technically good idea?
2. How big a change is it?
I can't recall what purpose separating the "etype" and "filetype"
serves in the current draft---it may simply be an artifact of evolution.
Without commenting further on the 1st question, let me address the 2nd:
There are basically 3 types of changes which would have to be made.
a. Delete references to "etype" and change to "filetype"
- modify 10.1 introductory text regarding "filetype" and "view"
- delete "etype" arg to FILE_SET_VIEW
- change a few other occurances of "etype" to "filetype"
b. Change offset from count of "etypes" to count of "filetypes"
- 10.1 Introduction: definition of "offset"
- 10.4.1 Introduction: Positioning: file pointer updates
- 10.4.2 {READ|WRITE}_EXPLICIT sentence defining "offset"
- 10.4.3/.4 Seek & Get_Position: sentence defining "offset"
c. FILE_SET_VIEW:
- Change text:
"the typemap of \mpiarg{etype} must be identical
on all processes in the group; values for \mpiarg{disp},
\mpiarg{filetype}, and \mpiarg{info} may vary."
to:
"values for \mpiarg{disp} and the datatype extents of the
\mpiarg{filetype}s must be identical on all processes in
the group; values for \mpiarg{info} may vary."
Item "a." is a minor change.
How big are items "b." and "c."?
NB: We may want to add the new text in item "c." above regardless
of whether we remove "etype"s or not. Without requiring "disp"
to be identical, two processes could define a view of
etype==filetype==MPI_REAL, one with byte displacement 1,
and the other with byte displacement 2---not exactly what we
originally intended.
- bill