GSOC Replies

[Joel Sherrill]

Wei Shen wrote:
> 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 <mailto:cquark at gmail.com>> wrote:
>  
>
>     O
>
> n 3/21/08, *Joel Sherrill* <joel.sherrill at oarcorp.com 
> <mailto: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.
>  
If you implemented this as a special file system type, do you think it 
is feasible
as a GSOC project to extra the common inode processing code into shared 
code? 
I don't know if this makes it a real VFS structure or just a shared set 
of methods
that makes filesystem implementation easier.
>  
> 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.
>  
This would be easy and could be a first step if you went to 
refactoring/extracting
common inode processing.
> 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.
>  
I agree with you and after some thought think it might be worth pursuing
a FIFOFS ONLY if you undertake to extract IMFS code and arrange to share it.

--joel
> Comments are always welcome.
>  
> Thanks,
> Wei Shen


-- 
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