POSIX FIFO/pipe

Joel Sherrill joel.sherrill at OARcorp.com
Fri Aug 15 20:03:27 UTC 2008


Wei Shen wrote:
> Hi Joel,
>  
> Could you help on some questions below :)
>  
Sorry.  I have been overwhelmed and when I miss something,
it tends to just get further and further away.

On a positive note, the kitchen remodel is nearly finished but
now that school is back in session I have 3 sons in high school
to help at night.  It has been a long time since I saw organic
chemistry. :-D
> =======================================
> On 7/26/08, *Wei Shen* <cquark at gmail.com <mailto:cquark at gmail.com>> wrote:
>
> ... ...
>
> Which location is prefered for pipe source files?
> Currently, cpukits/libfs/pipe/.
>  

> Any document on how to finish all the configuration scripts and 
> makefiles, and to add necessary configuration items?
>  

> Which location is prefered for pipe test code?
> testsuites/psxtest/ ?
>  
Hmm... if the code is enabled all the time, then no.  If this is strictly
POSIX pipes and only potentially available when POSIX enabled this
is the right place.

If this is being treated as an extended C library feature and you
have only dependencies on the classic api (which it sounds like is
the case), then you can put it in libtests where fileio is located.

Do you have functional building code when POSIX is disabled.
Is this true?  This is really an important deciding factor.

> Is psxtest ported from somewhere?
> I feel it is too consuming to design and implement testcases oneself.
>  
No.  Every line of code in there was written for the RTEMS project.

There are a few tests from other sources in the tree (paranoia
and ttcp come to mind) but most are original.

You might be able to find some pipe example code on the net
and port it but I never bother.
> At which level should the pipe module be initialized?
> Currently, I initialize the pipe module at the initialization of each 
> FS supports it (IMFS_initialize_support to be more specific).
>  
That is OK.  As long as it is an optional component and its resources
are well accounted for -- CONFIGURE_MAXIMUM_PIPES or something.
> In my code, I always carefully assume rtems_semaphore_obtain and 
> rtems_barrier_wait may fail (not timeout or destroyed). Is that necessary?
>  
I think that is a good and safe design assumption.  You never know
what is going to happen in real life.



--joel
>
> Thanks,
> Wei


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





More information about the users mailing list