[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Tue, 25 Mar 2008 15:01:07 +0800
- From: rayx.cn at gmail.com (x ray)
- Subject: GSOC Replies
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
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).
> 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
> 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
> 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.
> Wei Shen
Thanks & Best Regards!
- GSOC Replies
- From: joel.sherrill at OARcorp.com (Joel Sherrill)