rtems_filesystem_current issues

Till Straumann strauman at SLAC.Stanford.EDU
Sat Oct 26 02:09:31 UTC 2002


Hi

I spent the last week implementing NFS (client) support for RTEMS.
The implementation can't avoid attaching dynamical information to
the 'node_access' field of rtems_filesystem_location_info_t

This introduces subtle problems with the more or less global

rtems_filesystem_current
rtems_filesystem_root

variables. In particular, they must not be copied without properly
allocating a new node nor released without calling
rtems_filesystem_freenode().
While the generic FS code seems to be pretty clean (fchdir() and
chroot() are the exceptions  [I'll submit patches/PRs ASAP]) in
this respect - there are more problems with the 'userenv'
related stuff.

Wouldn't it make more sense to make the 'current' and 'root'
locations part of the C-library's per-thread 'reent' structure?

IMO, the current solution (they are part of the 'userenv') is not
a good one. Sharing the path variables is _not_thread_safe_ and
hence it would be better to explicitely having to ask for sharing
them (threads who do so are then responsible for proper
locking etc.) and implicitely getting a private copy rather than the other
way round.
Ideally, sharing these path locations should be avoided at all
(otherwise, the need for reference counts etc. arises).

RFC

-- Till




More information about the users mailing list