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