discussion related to implementation of File descriptor functions in RTEMS

[Sebastian Huber]

On 2020-03-27 18:41, Joel Sherrill wrote:

>
>
> On Fri, Mar 27, 2020 at 12:12 PM Eshan Dhawan <eshandhawan51 at gmail.com 
> <mailto:eshandhawan51 at gmail.com>> wrote:
>
>
>
>     On Thu, Mar 26, 2020 at 11:18 AM Sebastian Huber
>     <sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>         On 25/03/2020 20:33, Joel Sherrill wrote:
>
>>
>>
>>         On Wed, Mar 25, 2020 at 12:17 AM Eshan Dhawan
>>         <eshandhawan51 at gmail.com <mailto:eshandhawan51 at gmail.com>> wrote:
>>
>>
>>
>>             On Wed, Mar 25, 2020 at 4:01 AM Joel Sherrill
>>             <joel at rtems.org <mailto:joel at rtems.org>> wrote:
>>
>>
>>
>>                 On Tue, Mar 24, 2020 at 4:57 PM Eshan Dhawan
>>                 <eshandhawan51 at gmail.com
>>                 <mailto:eshandhawan51 at gmail.com>> wrote:
>>
>>                     Hello everyone,
>>                     As @Vaibhav Gupta
>>                     <mailto:vaibhav.varodek at gmail.com> suggested I
>>                     have also added adding file descriptor functions
>>                     to my GSOC project.
>>                     I went through the mailing list archives for more
>>                     information.
>>                     RTEMS as its own file descriptor so the functions
>>                     need to be implemented from scratch.
>>                     I wanted to get more information related to it.
>>
>>
>>                 What's the set of functions you are proposing for
>>                 those not tracking your draft proposal?
>>
>>             Link:
>>             https://docs.google.com/document/d/1n-JOFUbFn6V1kViAGWsEGbVHL9MxlMyKP0BbZhEA1Rs/edit?usp=sharing
>>             I haven't searched about the functions in the list yet.
>>             The list was made by Vaibhav, last year and he told me
>>             that it could be added to proposal this year as well.
>>             I read the archives that these need to be written from
>>             scratch.
>>
>>
>>
>>         Maybe not. I found at least this implementation of renameat()
>>         which was implemented on top of existing calls:
>>
>>         https://github.com/lattera/freebsd/blob/master/contrib/openbsm/bin/auditdistd/renameat.h
>>
>>         It should be in a C file but that shows it can be done. That
>>         directory has a lot of these methods.
>
>         Adding the *at() functions with an RTEMS-specific
>         implementation would be nice (and not difficult). The generic
>         renameat() implementation for example changes the current
>         directory. One of the goals of this API is to avoid exactly
>         this. In glibc/Linux for example a system call is used:
>
>         https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/renameat.c;h=901d61f37e10d0c2df245c01bb2ef980d00e8f52;hb=HEAD
>
>         https://github.com/torvalds/linux/blob/master/fs/namei.c#L4590
>
>
> I'm not disagreeing that a generic implementation is undesirable 
> long-term but these methods have not been present for 30 years and no 
> one has complained about their absence. I would propose generic 
> implementations be added and a ticket filed to add RTEMS specific 
> implementations if someone complains about the performance.
>
> I see adding them now as a higher effort task that brings little 
> value. These are for standards compliance and not performance critical.

I would prefer to have real implementations and not just a Potemkin 
village. Changing the current working directory (there is only on in 
RTEMS by default) can lead to hard to find bugs.

All these functions are probably easy to implement. With LIBIO_GET_IOP() 
and LIBIO_GET_IOP_WITH_ACCESS() you get the iop from the file 
descriptor. Then we have to add a variant of 
rtems_filesystem_eval_path_start_with_root_and_current() which uses the 
location of the iop as the initial currentloc. The root and current 
global locations can be set to rtems_filesystem_global_location_null.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200327/fa0758dd/attachment-0001.html>