TFTP driver changes

[Till Straumann]

Eric Norum wrote:

> Till Straumann wrote:
> > Here's an idea how (very rudimentary) relative path support could be added
> > to TFTPfs:
> >
> > - TFTPfs'  rtems_filesystem_node_type() returns 'RTEMS_FILESYSTEM_DIRECTORY'
> >    to any call with a pathname argument ending with a slash ('/').  It also stores (a
> >    copy of) the pathname in the node_access field. (hence the freenode method
> >    would have to be implemented also).
> >
> > - TFTPfs' rtems_filesystem_evaluate_path() assembles the absolute path
> >    from the prefix (stored in cwd's node_access) and the relative path argument.
> >    It then eliminates all occurrences of '.' and '..' before proceeding.
> >
> >    Note: this works only as long as no mount points or links are crossed (which
> >    are not implemented by TFTPfs anyway).
> >
> > The iocsh should then do a eg. chdir("/TFTP/BOOTP_HOST/epics/norumx3/blah/blah/")
> > when initializing. This will record "/BOOTP_HOST/epics/norumx3/blah/blah"
> > in the cwd structure.
>
> This looks like an excellent idea.  I'll see if I can find some time
> today to try it out.
> I've got some of questions since this is the first time I've really
> played with the RTEMS filesystem stuff.

Me too, i.e. I'm not really an expert regarding the RTEMS filesytem implementation.
I started having a look at the source for participating in this discussion which
is interesting to me, partly because I also want to use EPICS/RTEMS.

Here's what I have found out so far:

>
>
> 1) Does RTEMS have an concept of a `current working directory'?  If so,
> is it a system-wide or per-task value?  Also, if so, where is the
> information held?  How could the drive access this information?

RTEMS seems to have a per-task CWD ('current working directory') which is
part of the user environment. (rtems/libio_.h)


#define rtems_filesystem_current     (rtems_current_user_env->current_directory)

the directory is a

rtems_filesystem_location_info_t current_directory;

However, the 'filesystem_location_info_t' is more like a UNIX-style 'inode',
i.e. it does _not_ hold path name information (which is impossible when
the filesystem implements links). The node type is defined in <rtems/libio.h>
It basically consists of a pointer to the device specific file_ops and a pointer
to a mount_table_entry. Luckily, the node structure also provides a pointer
that seems to be for driver private use.


>
>
> 2) How can TFTPfs' rtems_filesystem_evaluate_path() tell whether the
> path it's been handed is relative or absolute?  At the moment the
> assumption is that the path is always absolute with the host-name as the
> component right after the /TFTP/.   Should the driver continue to make
> this assumption until it sees a chdir with a trailing (and perhaps
> leading) / character and then assume relative paths after that time?

The filesystem's evaluate_path() is only called indirectly. The RTEMS kernel
routine 'rtems_filesystem_evaluate_path()' inspects the pathname argument
and decides whether the pathname is absolute (leading '/') or relative (otherwise).
rtems_filesystem_evaluate_path() then uses either the root_node or the
CWD node (for relative lookups) for further lookup: it calls the starting node's
(either ROOT or CWD) eval_path() method passing it the path_name (leading
'/' stripped in case of ROOT) and the starting node.

A filesystem's eval_path() should then perform a step-by-step lookup
of the remaining path, carefully taking care of links and mount-point
crossings. E.g. when looking up "/TFTP/blah"
 - rtems_filesystem_evaluate_path() strips the leading '/' and calls
    the root node's (the root node being in the IMFS) 'eval_path()' method
    passing it 'TFTP/blah' and a pointer to the root node.

 - IMFS'  eval_path detects that the "TFTP" node is a mount point. It then
    calls the mounted filesystem's eval_path() (being the TFTPfs') eval_path()
    routine passing it "blah" and a pointer to the TFTPfs root node.

>
>
> 3) Does TFTPfs'  rtems_filesystem_node_type() have to store the copy of
> the absolute path in the node_access field (with all the freenode
> complications thus implied) or could it just store a copy using a
> file-static char * variable?   This relates to question (1).  If the
> current directory is a per-task value, I can't see how the system
> described by Till will work (since different EPICS tasks want to read
> different files).

Well - I guess I take back the "node_access" solution. After studying
the source a little, it seems that this is not an appropriate place.

1) How about simply having just one 'tftp path prefix' which applies to
the entire TFTPfs. All relative paths would then be evaluated with respect
to this prefix. The prefix could be initialized when initializing the filesystem.
There could be a routine to change the prefix at run-time.

2) Another solution could be using the mount point path name as a prefix, i.e.
not mounting TFTPfs on "/TFTP" but e.g. on "/serverA/epics/blah/blah".
In this scenario, TFTPfs could allow for multiple mounts of TFTPfs on different
mount points. It would then be possible to allow a task to chdir to the mount point
which would give rudimentary 'per task' CWD support. (The mount point path
name could be stored in the mount_table_entry's fs_info field). Unfortunately,
however, the 'mount_me()' method has no access to the mount point path name
which means that this solution cannot be implemented without other kludges...

3) Having TFTPfs implement a tiny 'IMFS' on its own, implementing directory
nodes which would provide server path information. Of course, this solution
is far more complex than 1).


-- Till