Hi Pete,
> > - char *link_target; /* NOTE: caller must free if valid */
> > - int dfile_count;
> > + uint64_t link_target; /* NOTE: caller must free if valid. Needs to be
> > uint64_t so that it is a fixed length entity */
> > + int32_t dfile_count;
>
> This is by far the most objectionable component, along with all the
> string casts. Could you use #ifdef on word size to avoid this?
Yes, indeed. Okay. I will change that then...
>
> > struct PVFS_sys_mntent
> > {
> > char **pvfs_config_servers; /* addresses of servers with config
> > info */
> > - int num_pvfs_config_servers;
> > + int32_t num_pvfs_config_servers;
>
> Are you saying int is 64-bit on ppc64? That would be very odd indeed.
> I find the need to encode the type for native ints quite intrusive. Is
> this really the way these things are handled?
Well, LP64 is generally the preferred data model but I am not sure if
ILP64 is followed by any architecture (although that would break tons of
applications, I am sure). All I wanted was to fix the sizes
of structures so that they would be the same regardless of 32/64 bit
issues. If you have any suggestions, do let me know or I will let them
stay the way they are.
> > + tmp_cflags=$CFLAGS
> > + CFLAGS="$CFLAGS"
>
> What good does this do?
No clue... :) I just cut and pasted from the previous lines (obviously
incorrectly though)!.
I will fix those...
>
> > - size_t amt_complete;
> > + int64_t amt_complete;
>
> size_t is unsigned, int64_t is signed.
Hmm.. If you look at pvfs2-client-core, which fills in these values after
the I/O operation is done from the response, all those types are PVFS_size
which is typedef'ed to int64_t. Hence I did the same.
Should this be changed to uint64_t when PVFS_size itself is int64_t?
>
> > - loff_t readahead_size;
> > + int32_t readahead_size;
> > } pvfs2_io_request_t;
>
>
> Lost precision here, 64->32. Do possible values still fit?
This piece of code was already pretty loose about precision prior to the
change. If you look at pvfs2-client-core, it constructs
PVFS_Request_contiguous types before the readahead, and then there is a
cast to an int32_t since PVFS_Request_contiguous requires an int32_t.
So I dont know whether it is worth fixing those.. It seemed easier to fix
this.
That said, I dunno if we would ever request more than 2 GB of read-ahead!
This code is triggered only for executables/mmap(MAP_PRIVATE, RDONLY) as
it stands
> > + {
> > + int ret = 0;
> > ret = copy_from_user(
>
> No need to initialize to zero if you're immediatly giving it a value
> (three places).
Okay :)
Will change those as well!
>
> In spite of the little comments above, I think this is important to
> do and good stuff. But testing on all-64 and all-32 arches has to
> happen to watch out for conversion bugs.
Thanks a lot for the comments and suggestions, Pete!
Regards
Murali
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
