Hi,<br><br>
<div><span class="gmail_quote">On 3/21/08, <b class="gmail_sendername">Joel Sherrill</b> <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>> wrote:</span></div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>I am torn between a dedicated filesystem and adding a filesystem to the<br>IMFS.  The dedicated filesystem makes sense and is cleaner./  If you<br>
don't want this capability, don't mount it.<br><br>Make sure about the pipe() and mkfifo() calls.  Careful reading of the<br>opengroup standard may force a decision.  I hope we can get away with the dedicated filesystem.  It sounds cleaner and easier to drop out.</blockquote>

<div> </div>
<div>Today, I studied the RTEMS FS and IMFS implementation. Seems hard to implement FIFO as a virtual fs, for the lack of a complete vfs layer and file-<span id="Mark" style="COLOR: #ee6600; BACKGROUND-COLOR: yellow">node</span> abstraction in RTEMS.</div>

<div> </div>
<div>If we want to make FIFOFS entirely independent of the host FS which a fifo file resides, we would have to:</div>
<div>1) define a new data-structure for FIFO filenodes, which repeats many identical fields (atime, uid, ...) with host FS structures (e.g. jnode in IMFS).</div>
<div>This is required because otherwise the file handers of FIFOFS can not understand the <span id="Mark" style="COLOR: #ee6600; BACKGROUND-COLOR: yellow">node</span>_access structure passed to them from the FS interface.</div>

<div> </div>
<div>2) reimplement a full set of FS handlers.</div>
<div>Since filenode structure is changed, handlers of the host FS can no more be used.</div>
<div> </div>
<div>3) hook many places in the host fs, to add special handling for FIFO files.</div>
<div> </div>
<div>An OS with a complete VFS layer needs not to do all these, because FIFOFS can share a common VFS <span id="Mark" style="COLOR: #ee6600; BACKGROUND-COLOR: yellow">node</span> structrure (e.g. inode in Linux) and many FS handlers (i.e. inode operations) with host FSes, and the VFS layer is respossible for maintaining file <span id="Mark" style="COLOR: #ee6600; BACKGROUND-COLOR: yellow">node</span> attributes. Usually, only needs to hook a few FS routines like mknode and open.</div>

<div> </div>
<div> </div>
<div>An alternative implementation is to design a FIFO interface to FS and implement part of file handlers demanded (open, write, rmnod, ...). FSes should provide a set of handlers (as IMFS currently done for device files) specific to FIFO files that invoke the FIFO interface and maintains filenode (e.g. jnode) states. Part of the FIFO handlers (that do not alter filenode states) can be directly plugged into the file handler table of the host FSes.</div>

<div> </div>
<div>By so, FIFO can still be encapsulated into a independent module, but only requires a little modification on FS code.</div>
<div> </div>
<div>The open project page suggests: "For unnamed pipes, we could create a named FIFO using a temporary name. ... place them possibly in a special directory". I originally think it is unnecessary, however, also due to the lack of a VFS <span id="Mark" style="COLOR: #ee6600; BACKGROUND-COLOR: yellow">node</span> structure, it seems to become a problem, for we have to create a jnode (for the case of IMFS) to preserve file states (atime), and maybe the easiest way to acheive that is creating a IMFS file.</div>

<div> </div>
<div>Comments are always welcome.</div>
<div> </div>
<div>Thanks,</div>
<div>Wei Shen</div>