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...
Yes by all means...
>
> > 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...
Both have their good points. I am not going to state who is and is not
better.
I personally like the "added features " of RTAI and the kernel patch for
RTAI seemed to be less obtrusive. ( My views only No flame wars on this
. Close debate please ).
>
> 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...).
A question of choice.
The simple fopen command with the "a" append option will create the file
if it is not already there.
There are times when you may want to start one application without the
other.
In a typical case you do not want to start a real time data collection
task before the user task is ready to receive data. The fifo will be
filled with stale data in this case which must be cleared before the
"real" data is processed.
In the past I have had to use 2 fifos to make this work, with the user
space create I can get by with only one.
I do not consider this a user friendly patch up for sloppy code but a
good feature for use in certain design cases.
>
> - 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...
>
This is a bit short sighted.
I give the user more credit than that.
Most true designers welcome the removal of entry barriers but still know
they have to do their homework even if it did work by chance the first
time.
> - 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?
>
I cannot agree more with you here...
I and others have been working towards this goal for quite a while now.
The Fifo area is one place that some sort of common API is easily
created.
> - 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...)
I could be candid and say RTFM but the answer is yes it is a real fifo
and in fact in the README.FIFO snippet you had part of your answer.
>
> --
> [EMAIL PROTECTED] (Ph.D.) Fax: +32-(0)16-32 29 87
> Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium
Delighted to have a discussion on this..
Phil Wilshire
-- [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/
