`clever' C preprocessor trick now causes problems

[Till Straumann]

Eric Norum wrote:

> I'm using RTEMS as a platform for EPICS (Experimental Physics and
> Industrial Control System).  The EPICS sources assume a full NFS
> connection to the file server and opens files with pathnames like:
>         ../foobar.dbd
>         ../../db/bletch.db
>         ./blahblahblah.cmd

But typically, these particular files are loaded by a script
during IOC initialization. Modifying the script would be easy.

One more thing puzzles me: if the server does relative path lookups,
it must somehow have chdir()ed before trying to open these files.
Now: RTEMS' tftp filesystem doesn't support directorys - a chdir by
the server should fail anyway???

I guess, what I'm trying to say is: are there really filenames that are
hardcoded into IOC core that would have to be modified?

>
>
> To provide similar functionality on RTEMS I compile the EPICS sources
> with a `-Dfopen=rtems_fopen' command-line flag.  The rtems_fopen routine
> strips off any leading ./ or ../ characters, prepends
> /TFTP/<<bootp_host>>/epics/<<hostname>>/ and then passes that name to
> the real fopen routine.  Neat trick, huh?  I thought so too, at the
> time.  Now I don't.  :-(
>
> The problem is with the C++ headers in gcc-3.0.  In particular,
> g++-v3/bits/std_cstdio.h which has:
>

-- snip --

> Suggestions?

In this case, neither gcc nor EPICS seems to be the problem but the
rudimentary
implementation of filesystems in RTEMS and the lack of directory support in
TFTPfs.

Does anybody have an idea about how hard it would be to port an NFS client
to
RTEMS?

-- Till