fs ops was Re: change log for rtems (2010-06-22)

[Chris Johns]

On 24/06/10 9:58 PM, Joel Sherrill wrote:
> On 06/24/2010 01:53 AM, Ralf Corsepius wrote:
>> On 06/24/2010 08:28 AM, Chris Johns wrote:
>>> On 24/06/10 12:09 PM, Joel Sherrill wrote:
>>>> On 06/23/2010 05:57 PM, Chris Johns wrote:
>>>>> On 24/06/10 1:05 AM, Sebastian Huber wrote:
>>>>>> On 06/23/2010 04:57 PM, Joel Sherrill wrote:
>>>>>>> On 06/23/2010 07:23 AM, Sebastian Huber wrote:
>>>> #define rtems_filesystem_default_read \
>>>> (rtems_filesystem_read_t) rtems_filesystem_operations_stub
>>>> #define rtems_filesystem_default_write \
>>>> (rtems_filesystem_write_t) rtems_filesystem_operations_stub
>> I am opposed to using this paradigm. As Chris's reply implied, it means
>> lying to the compiler.
>> IMO, it will lead to unsafe and silently broken code.
>>
> OK. Our first approach was actually to add individual
> stubs for each method with the appropriate type. I just
> wanted to mention this approach since it is clearly
> lighter on code space. I honestly didn't think you
> all would like it. :)
>
> The stubs will be in a directory by themselves under
> libfs/src.
>
> To summarize some thoughts..
>
> + Some stubs should return "not supported". This will
> make the system calls return without special checks.
> + Others should do nothing and return OK. If these
> can replace operations in existing filesystems,
> then do it.
> + Both of the above will allow conditional checks in
> system calls to be eliminated.
>
> The following needs to be documented.
>
> + Some entries must exist and be functional if the
> filesystem is functional:
> + mount and unmount
> + open and close? (can't return ENOTSUP at least)
> + some of the evals
> + A set is required for readable file systems
> + A set is required for writeable file systems
> + Some are completely optional
>
> An implementation thought...
>
> + We will add a routine that checks the fields in the filesystem
> handler structure and returns false if any are NULL. This will
> replace the code checking for just mount/unmount.
>
> + Can this check above be marked as RTEMS_DEBUG? This isn't something
> that should catch anyone at run-time in a "real system".
>

You have do this in the mount after the initialise call. This is the 
first time you have access to the full ops table exported by the file 
systems. In time I would like to remove the ops tables from public 
headers. Given mounting is not something done often it could be left in 
but it is something that should not change once tested unless under 
development so the test and the code is redundant in a tested and 
production system.

Using RTEMS_DEBUG this way raises an interesting question. Do we need to 
always test with RTEMS_DEBUG and without to be certain all expected 
tests pass ? I do not use RTEMS_DEBUG this way and was not aware it 
could be used this way.

Chris