Hi Herman,
All valid points. I don't think it is a huge issue, both approaches are
valid. The portable/newfifos is a superset of the RTL fifos and so the
same API applies to the common set. If it has all the features you
need, use the RTL version as it is smaller, if you need the extended
functions (also has IPC's) use the portable version. The only idea is
to offer something in addition, and that was common to RTL/RTL. Note
the next release has named fifos, I hope this may be useful to all
RTL/RTAI, and I hope if it is seen as useful it can become natively
available in RTL too in a compatible way.
Regards, Stuart
Herman Bruyninckx wrote:
>
> On Thu, 13 Jul 2000, Phil Wilshire wrote:
>
> Phil,
>
> I hope you can comment on my comment on this post of yours...
>
> > The zentropix package ( Yes I do work for them ) allows you to create a
> > fifo from a user space program.
> [...]
> > > To make them easier to use, fifos can now be created by the user at
> > > open time. If a fifo that does not exist already is opened, it is
> > > created with a 1K buffer. Any following creation on modules side
> > > resizes it without any loss of data. Again if you want to create a
> > > fifo from the user side with a desired buffer size you can use: -
> > > rtf_open_sized(const char *dev, perm, size).
>
> ... in combination with Victor Yodaiken's independent reply to the
> original post, in which he (Victor) claims that the RTL approach is
> ``easier to use'' because it is clear and simple...
>
> All depends on the definition of ``easier to use'' of course... My (very
> non-authorative) ideas and questions about this issue:
>
> - A `feature' like ``If a fifo that does not exist already is opened,
> it is created with a 1K buffer'' carries IMHO the danger that is
> found all over the place in so-called ``user friendly'' software:
> the fact that the fifo does not exist already and the user tries to
> access it nevertheless looks (to me at least) very much like a
> programming error from the user, and ``hiding'' this error from the
> user by not telling him and using a default _will_ give problems
> later on (which will be _much_ more difficult to trace...).
>
> - Moreover, the 1K default is another source of potential errors: for
> example, a user writes a first program, using a fifo created by default
> and the buffer size doesn't create problems _for that particular_
> program. He thinks ``waw, nice feature, doesn't have to bother about
> fifos ever again'', and the next time he writes another program
> (needing much more than a 1K buffer!) and oops, program doesn't work
> anymore...
>
> - as a user the most ``user friendly'' thing I can imagine is _one single_
> well defined and well documented and unambiguous way to work with a
> given concept (i.c. fifos)... I don't know how this is solvable in
> the RTL-RTAI world ;-) Through the ``common API'' initiative perhaps?
>
> - is the fifo created from user space (by default or not) fully
> compatible with the real time space view on this same fifo?
> I mean: can any real time task work with this fifo without having to
> know how it was created? Same question for a user space task.
> (Sorry, but I didn't look at the details of all the fifo code in all
> different packages...)
>
> --
> [EMAIL PROTECTED] (Ph.D.) Fax: +32-(0)16-32 29 87
> Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium
>
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
