GSOC Replies

[x ray]

  It is interesting that in one mail yesterday I am talking about
remove fs support while today, I am talking about add new feature to
fs.
  I must admit that current support in IMFS is not so flexible. The
FIFO_fs is just a beginning. If we want to support more fs like yaffs,
jffs3 etc, VFS is more suitable. So I believe VFS will benefit RTEMS
in long term.
  However, we do not have enough resources now for VFS support. And it
is hard for a student finish this in a summer. So what I suggest is we
begin with your alternative way(small changes in IMFS and plug fifo
interface into hostFS (IMFS)). And let's see what can we achieve.


2008/3/25, Wei Shen <cquark at gmail.com>:
> Hi Joel, Ray, and all,
>
> I know you are rather busy to reply all the mails, but if it does not bother
> too much, can I request for some comments on my previous investigation on
> FIFOFS (see attachment).
>
> Thanks,
> Wei Shen
>
>
> On 3/22/08, Wei Shen <cquark at gmail.com> wrote:
>
>
> > O
> n 3/21/08, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>
> >
> > I am torn between a dedicated filesystem and adding a filesystem to the
> > IMFS.  The dedicated filesystem makes sense and is cleaner./  If you
> > don't want this capability, don't mount it.
> >
> > Make sure about the pipe() and mkfifo() calls.  Careful reading of the
> > opengroup standard may force a decision.  I hope we can get away with the
> dedicated filesystem.  It sounds cleaner and easier to drop out.
>
>
> 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,
> especially a VFS inode abstraction in RTEMS.
>
> If we want to make FIFOFS entirely independent of the host FS (e.g. IMFS)
> which a fifo file resides, we would have to:
> 1) define a new data-structure for FIFO file-nodes, which repeats many
> identical fields (atime, uid, ...) with host FS structures (e.g. jnode in
> IMFS).
> This is required because otherwise the file handers of FIFOFS can not
> understand the node_access structure passed to them from the FS interface.
>
> 2) reimplement a full set of FS handlers.
> Since filenode structure is changed, no handler of the host FS can be used
> any more.
>
> 3) hook the host fs (in many places) to add special handling for FIFO files.
>
> An OS with a VFS inode abstraction needs not to do all these, because FIFOFS
> can then share the common inode structrure and many FS handlers (i.e. inode
> operations) with host FSes, and the VFS layer is respossible for maintaining
> inode attributes. Usually, only needs to hook a few FS routines like mknode
> and open.
>
>
> 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.
>
> By so, FIFO can still be encapsulated into a independent module, but only
> requires a little modification on FS code.
>
> 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 inode structure, it seems to become a problem, for we have to
> create a jnode (in the case of IMFS) to preserve file states, and maybe the
> easiest way to acheive that is creating a IMFS file.
>
> Comments are always welcome.
>
> Thanks,
> Wei Shen


-- 
Thanks & Best Regards!

Ray, Xu