Details regarding Bug #1383

[Chris Johns]

Santosh vattam wrote:
> Hi Chris,
> 
>> The bug report deals with RTEMS internals only not the external interface.
>> That is a separate issue.
> 
> I don't understand what it means when you say RTEMS internals and
> external interface,  can you please elaborate? Is it that internal to
> RTEMS means a part of the RTEMS core and external interface consists
> of the external libraries that RTEMS uses and all its support tools?
> 

The external interface I refer to is libc or newlib. RTEMS is concerned about 
following standards where ever possible. I understand from Ralf this is being 
looked at in newlib.

The internal interface is the file system handlers that map to the specific 
file system code.

>> I found newlib defines '_off64_t'. What needs to be decided is the type for
>> RTEMS's internal use so the file system handlers and similar interfaces can
>> be changed to 64bit. Once the internal interfaces have changed the required
>> external interface can be changed or added.
> 
> What needs to be done to decide this? Can I be of some help regarding
> this? I mean is there a way I can recreate the bug as well as test a
> few hacks like the one given in the updated bug report?
> 

I will update my code and create a suitable patch which I will add to the PR. 
Once this is done and if no objections are received Joel can ask for the patch 
be applied to CVS. It is difficult for comment to be made without a patch.

A final comment on the need for this patch. If newlib is looking at this topic 
and will provide a type for a 64bit offset then do we need a patch inside 
RTEMS that does the a similar thing ? I do not know the answer to this as I 
have not seen what newlib will do. So do we wait for newlib or not ? The 
problem with newlib is the once per year release.

>> A search of the SUS only returned off_t and lseek while loff_t, off64_t,
>> lseek64 and llseek where not found. The nature of off_t is not detailed. I
>> suppose the external interface is a standards view, ie Darwin, verses a
>> compatibility one. I have hacked a local copy of RTEMS to internally support
>> 64bit offsets so the dosfsck tool could be ported. I am using it on a 4.3G
>> disk and so the 32bit offset failed.
> 
> Can I get more information about this hack so that I can apply it and try too?
> Thanks in advance
> 

I suggest you add yourself as a CC to the PR. You will then see any traffic 
related to the PR.

Regards
Chris