GSOC Replies

[x ray]

I agreed with Joel because (1)not try to introduce big change at one
time (2) each milestone is reachable (3)when each milestone achieved,
user's application will not break.

The drawback is, there might be some duplicate job.

Wei, what is your opinion ?

2008/3/25, Joel Sherrill <joel.sherrill at oarcorp.com>:
> x ray wrote:
>  >   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.
>  >
>
> Yes that is the way of RTEMS.  It is a balancing act.
>  Some users want the smallest possible tasking system
>  and would be happy with nothing more than probably
>  preemptable priority scheduled tasks and counting
>  semaphores.  In small systems you could use the counting
>  semaphores as simple binary ones for mutual exclusion.
>
>  On the other end of the spectrum is code that is
>  indeed real-time but needs a TCP/IP stack or logs
>  data to disk/flash.
>
>  Some boards RTEMS runs on have little besides a CPU,
>  RAM and a clock tick source while others are very full
>  features.
>
>  That's why we strive to keep RTEMS a system of modular
>  pieces that can be put together in a variety of ways.
>  TinyRTEMS is in many ways just breaking dependencies
>  between pieces we historically thought all applications
>  would want.
>
> >   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.
>  >
>
> RTEMS also follows a very iterative and conservative
>  development path.  We don't deliberately go out of our
>  way to break existing code -- it does happen but we try
>  to minimize it.
>
>  So I would propose this path:
>
>  + Add FIFO to IMFS to get code working.
>  + Refactor it into a FIFO FS.  It works again.
>  + Refactor again to get shared base data structure and
>  helper code which is effectively the VFS support.
>
>  Doing it all at once would be hard and might make it hard
>  to recognize refactorable code.
>

I

> >
>  > 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
>  >
>
>
>
> --
>
> Joel Sherrill, Ph.D.             Director of Research & Development
>  joel.sherrill at OARcorp.com        On-Line Applications Research
>  Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
>
>
>


-- 
Thanks & Best Regards!

Ray, Xu