OK. I’ll answer the question. I think this work would take me more an afternoon and would involve modifying several files by changing types in function prototypes. But, then there is also testing to make sure it doesn’t break anything.


Before I go on to anything else – casting the return value from aio_return64() to DWORD is a workaround for the potential issues I found. Not to mention a lot less work.


I’m going to guess the work to make large file transfers work would include:




                        GetQueuedCompletionStatus() – type for bytes_transfered becomes pointer to off_t

                        ReadFile – type for bytes_read becomes pointer to off_t

                        WriteFile – type for bytes_written becomes pointer to off_t


                        CQ_Element.bytes_transfered becomes off_t



                        CQAIO::GetStatus – type of bytes becomes pointer to off_t

-          remove cast to (DWORD *) in call to GetQueuedCompletionStatus()


            Transaction.size becomes off_t





At this point you get the idea – there are a large number of small changes to get this incorporated into the source. These changes will ripple through about half the files used to build dynamo.







-----Original Message-----
From: Daniel Scheibli [mailto:daniel.scheibli@edelbyte.org]
Thursday, May 27, 2004 2:34 AM
To: Tieman, Henryx W; iometer-devel@lists.sourceforge.net
Subject: Re: [Iometer-devel] File offset type question



could you please provide us with a estimation regarding the number of files/locations
- so the efforts involved in doing this change.

If it is handable/overseeable I would tend to agree on apply it to IOMETER2 (HEAD
branch in CVS) but not in IOMETER1 (IOMETER1 branch in CVS).


Wed, 26 May 2004 14:32:00 -0700, Tieman, Henryx W wrote
I have run into a place where I want to know what the other developers think. If you have feeling about this just let me know.
I ran into a problem doing working on a 64 bit Linux port. There is one I/O status function that always returns a 64 bit number in Linux - aio_return64(). But, the return value from aio_return64() is always stored in a 32 bit value. I’m not too worried about the regular assignments but there are 3 assignments to dereferenced pointers. I think these three calls always put 0 in the top 4 bytes, but that depends on the compiler.
There are a few ways to deal with this. Cast the return from aio_return64() to a DWORD is the easiest, but it may have to change later to deal with huge files. Another possible solution, would be to change the DWORDs that hold the number of bytes read to off_t, but that affects many source files.
Since going to using off_t has major implications I want to know how the developers in this list felt about that kind of deep change.
If you have an opinion on this let me know.