Details regarding Bug #1383

[Joel Sherrill]

Chris Johns wrote:
> 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.
>
>   
This only impacts the problems we are solving on the CVS head.
Chris is using a free software DOS format command and adding it
to the RTEMS Shell.  For this to work, we need seeks > 32 bits.

I think this is a very important issue but as Ralf and Chris have
explained, different OSes have different solutions.  A move to
64-bit off_t would be the simplest but push 64-bits into the
commonly used APIs for the first time.  Adding 64-bit seeks
is a possibility but that is more work and adds more interfaces.

So neither solution is technically hard but neither is head and
shoulders obviously right.
> 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.
>
>   
Once newlib has a solution, I expect we will take the patch and
use it ourselves on the 4.10 tools.

It would be good to come to some resolution.  Ralf.. can you update
us on the newlib direction?  And what you recommend. 
>>> 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
>