I've made a tftp file system. Relatively straightforward w/eCos.
Mounting this device at /tftp, I can read/write files using the
following path syntax: /tftp/10.0.0.106/filename... This
adds tftp client get/set to my app without modifying the app.
However, tftp_client_put() needs to be done at close() time and
FILEIO_MUTEX_LOCK(fdlock) is held when co_close() is invoked.
fo_sync() is not invoked when the application (which I can't
really modify) calls close().
With the attached patch, I no longer get the deadlock, but I don't
quite understand this code or API contract well enough
to know how and why the FILEIO_MUTEX_LOCK(fdlock) should be
held.
Would it be possible to rewrite io/fileio/current/src/fd.cxx not to
hold FILEIO_MUTEX_LOCK() during fo_close() without
breaking something?
Should close() invoke fsync()?
--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit
### Eclipse Workspace Patch 1.0
#P ecos
Index: io/fileio/current/src/fd.cxx
===================================================================
RCS file: /cvs/ecos/ecos/packages/io/fileio/current/src/fd.cxx,v
retrieving revision 1.7
diff -u -r1.7 fd.cxx
--- io/fileio/current/src/fd.cxx 7 Apr 2004 11:18:54 -0000 1.7
+++ io/fileio/current/src/fd.cxx 18 Jan 2008 12:22:41 -0000
@@ -157,7 +157,11 @@
{
cyg_file_lock( fp, fp->f_syncmode );
+ FILEIO_MUTEX_UNLOCK(fdlock);
+ // closing the file might involve other file operations, e.g.
+ // tcp/ip communication on sockets.
error = fp->f_ops->fo_close(fp);
+ FILEIO_MUTEX_LOCK(fdlock);
cyg_file_unlock( fp, fp->f_syncmode );
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
