TFTPS losing current working directory in 4.10
angus.gratton at anu.edu.au
Mon Jul 19 05:39:03 UTC 2010
I've been bringing up EPICS against RTEMS 4.10 and I'm having some
For TFTP file access, I've had to make a couple of minor tweaks on the
client side for changes in the filesystem API. Also two very minor
tweaks in RTEMS for some corner cases of hostname resolution (will
provide patches for both lots when I'm done.)
However I've now come across something quite weird that seems more
fundamental. The behaviour I'm seeing is:
- EPICS startup sets the cwd to /TFTP/<host>/epics/<client hostname>.
This value is stored in pathloc->node_access by rtems_tftp_eval_path.
- First file request loads a relative path from the filesystem. This
works, pathloc->node_access has the cwd and the whole thing resolves
- Second file request is a relative path. At this point, the lookup
fails. The tftpfs is still consulted but the value in
pathloc->node_access has changed from the cwd to the string "VERS" and
the lookup fails (VERS is not a known host.)
- Third file request is a relative path. Also fails, but now because the
pathloc->node_access value has changed to the empty string.
It looks and feels to me like a memory corruption issue, but I'm hoping
it might ring a bell for someone else before I keep going on.
I've been using RTEMS 4.10 so it is possible this doesn't occur in the
current CVS. The tftpDriver.c file hasn't changed, but this looks like
it may be a problem with underlying filesystem layer, or something
totally unrelated that I'm doing in my code.
If it doesn't ring any bells then I'll put together a simple RTEMS test
app and try to debug it from there.
(On a related note, has anyone used the powerpc GDB remote stub under
RTEMS 4.10? It looks like a great tool, but I haven't been game to build
More information about the users