Hi Victor,
I take your points, and I fully understand the motivations behind the
_np functions you offer. However, I think that the danger is people
will start to use these functions in the belief that they are in some
ways POSIX and therefore part of the standard, when this is clearly not
the case.
I hope you will give serious consideration to supporting a standard
POSIX approach such as the module found in RTAI. The parts that are
missing, such as clocks can be added as they are developed, with the
original API being used to fill in in the interim.
Regards, Stuart.
[EMAIL PROTECTED] wrote:
>
> On Mon, Dec 20, 1999 at 04:42:56PM +0000, Stuart Hughes wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > [snip]
> > >
> > > See hrtime_t clock_gethrtime(clockid_t clock)
> > > and
> > > pthread_make_periodic_np
> > >
> > > Any problems with those?
> >
> > Yes, pthead_make_periodic_np is not in any POSIX standard. For those
> > wishing to make their code portable, which is the primary purpose of
> > using a POSIX API, any calls suffixed _np will destroy this possibility.
>
> I must have misread your earlier comment which I thought asked for
> a nanosecond interface to clocks on the V1API. The pthread_make_periodic
> is intended to export the V1 simple functionality to V2 while replacing
> "ticks" with nanoseconds.
>
> > IMHO, it would be better to stick with standard POSIX and use POSIX
> > clocks for timing. If this is too painful to users or people do not
> > want to use POSIX, the original NMT/RTAI API provides a simple
> > alternative.
>
> As you noted, the V1 RTLinux API has an unpleasant dependency on the 8253
> timer. One of the reasons that we went to the V2 API is that we did not
> see a clean way of repairing the defects in V1.
--- [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/
