change log for rtems (2010-06-15)

[Chris Johns]

On 17/06/10 6:08 PM, Ralf Corsepius wrote:
> On 06/17/2010 09:53 AM, Chris Johns wrote:
>> On 16/06/10 8:40 PM, Ralf Corsepius wrote:
>>>
>>> => rtems_rfs_fs_size is broken. The uint64_t cast is dysfunctional.
>>>
>>
>> I attach a patch for HEAD and 4.10. Is this ok to apply ?
> Now, I am confused.
>
> After having applied further changes, I reverted my change ... to be
> checked
>

I reviewed the code and decided to implement functions in a C file. What 
further changes did you make that effected this code ? I reviewed all 
changes and did not see anything.

I would prefer this patch over the original code. Does this patch effect 
your changes ?

>>>
>>> 64bit filesystems are
>>> * non-applicable on machines without 64bit support.
>>
>> I was referring to support for 64bit sized file systems and 64bit file
>> offsets not the target characteristics.
> Well, in the current rfs implementation in RTEMS, these are not clearly
> separated.
>
> To put it less theoretically: rfs will not be usable if a
> target/toolchain doesn't support 64bit types and will be ineffective

I suspect 64bit file handling would be difficult if this is the case no 
matter what the file system is. I have assumed uint64_t is provided. 
Will RTEMS ever support target tools that do not provide uint64_t ?

Supporting 64bit files does not mean all operations are using 64bit 
values. Almost all operations are based on blocks and block numbers and 
these are 32bit. Yes a 64bit value is used during superblock parsing and 
format operations but this is not a hot path.

> (slow) to use on targets which don't have 64bit instruction sets (IIRC,
> gcc emulates 64bit on some targets).

I suspect gcc emulates 64bit operations for all targets that do not have 
64bit maths hardware. ;)

As for slow, this is the domain of our users. If the RFS with 64bit 
support is too slow I am sure they will complain and we can look at it 
or they will find another solution and we will all benefit.

I happen to know this code is running on a slow Coldfire core accessing 
a special RAM disk to feed a high speed link.

Chris