On Thu, 16 Aug 2001, Victor Yodaiken wrote:
> On Thu, Aug 16, 2001 at 06:28:16PM -0400, Calin Culianu wrote:
> > On Thu, 16 Aug 2001, Victor Yodaiken wrote:
> >
> > > On Thu, Aug 16, 2001 at 04:17:48PM -0400, Calin Culianu wrote:
> > > > Notice that unlike the rtf_put() function in rt-linux, the read() system
> > > > call actually was well enough written to work with void *. It escapes me
> > > > why the rt-linux developers chose char * as opposed to void * for their
> > > > second argument to rtf_put(). All I have seen it to do to date was
> > > > confuse novices. Can anyone enlighten me on this fine point?
> > >
> > > Yes. The answer is "lack of thought" - rtf_put was quite early and the early
> > > UNIX "read" was prior to the invention of "void *" so we didn't think about
> > > it.
> > > Note that RTLinux now has a POSIX interface to RTF and you can do
> > > fd = open("/dev/rft2",O_WRONLY | O_NBLK );
> > >
> > > write(fd, voidpointer, n);
> > >
> > > To make things nicely symmetrical.
> >
> > Ah.. so rtlinux implements some posix functions like open() and write()?
> > Are these basically wrappers to lower-level kernel functions like
> > filp_open in fs/open.c? (You couldn't use sys_open since this is all
> > kernel space).
>
> Yep they are wrappers. sys_open would be dangerous. The advantage of the posix
> functions is that when we optimize rtfifos we can do so transparently, but it's
> going to be harder to do that with the rtf_put/get api.
>
> > Hey.. I know this is a newbie-style question: but what are the advantages
> > of RTF files over regular fifo's? Do they have some guarantees as to the
> > fact that any non-realtime tasks waiting on them are more likely to get
> > awoken right away?
>
> The rtfifos are designed to make sure that the RT side cannot block on operations of
> the non-RT side. We will add blocking to the read/write interface, but the basic
> RTL idea is that RT components _never_ block unless they specifically ask for it.
> RTfifos do something peculiar - they provide an interface between the RT world
> and Linux so the implementation looks very different on the two sides.
Ok, so for argument's sake say you had something like data that flows in
one direction only: It goes from the RT world to non RT world in user
space. Let's say a data acquisition application samples data at 1kHz and
needs to tell a user process about this data.
Is there any advantage to stuffing this data in a RTF or would putting it
somewhere like a regular FIFO be equivalent for these purposes?
Basically this is a question about the internals of the behavior of
regular FIFO's as opposed to RT Fifo's. I am assuming rt fifo's have
buffers that lie completely in non-swappable ram, etc, so as to make
blocking/delaying on writes impossible...
Is this the case?
-Calin
>
> >
> > -Calin
> >
> > >
> > >
> > > >
> > > > -Calin
> > > >
> > > > >
> > > > > mbuff looks interesting but I have found the doc to be sparse.
> > > > >
> > > > > I am sure that many of you have had to do this, so I would like to hear your
> > > > > opinions. Code snippets would be appreciated to help me along.
> > > > >
> > > > > Thank-you!
> > > > >
> > > > > Oliver
> > > > > National Test Pilot School
> > > > >
> > > > > -- [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/
> > > > >
> > > > >
> > > >
> > > > -- [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/
> > >
>
-- [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/
