Re: VIRUS ALERT was:[rtl] RTAI and RTLinux

[Norm Dresner]

 Anti Virus pops up and asks me what to do with anything it deems offensive,
but as much as I hate/fear the virus programs being distributed, I'd still
like to be in the loop for deciding what gets dumped and what I keep.

Norm


- Original Message -
From: Thomas Frasher <[EMAIL PROTECTED]>
To: 'Dresner, Norman A.' <[EMAIL PROTECTED]>; 'RTLinux'
<[EMAIL PROTECTED]>
Sent: Wednesday, March 28, 2001 5:53 PM
Subject: RE: VIRUS ALERT was:[rtl] RTAI and RTLinux


> There is a patch to the outlook to prevent any attachements that are
deemed
> infected.  it works.  I don't even get to see the attachments that are
> scunged.
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Dresner, Norman A.
> Sent: Wednesday, March 28, 2001 7:58 AM
> To: 'RTLinux'
> Subject: FW: VIRUS ALERT was:[rtl] RTAI and RTLinux
>
>
> This message just came in with an attachment called Emanuelle.exe that
> Norton Anti-Virus said was a virus.
>
> While I think that attachments are a useful part of our mailing list,
we've
> got to start filtering them to kill all .exe, .com, .vbs, ... that will
> execute on a Windows system -- which is my primary mail client in all
> locations.
>
> Norman Dresner
> Fellow Systems Engineer & SGI Laboratory Administrator
> Radar Systems Engineering Department
> Electronic Systems and Sensors Segment
> Northrop Grumman Corporation
> Baltimore-Washington International Airport
> 7323 Aviation Boulevard
> Baltimore Maryland 21240
>
> Voice: (410) 993 - 2096 Mornings; all-day voice-mail
> (410) 969 - 8068 Afternoons with answering machine
> FAX: (410) 993 - 8084 On-site
> (410) 969 - 8068 Afternoons; call first to arrange
> E-Mail: Mornings: mailto:[EMAIL PROTECTED]
> Afternoons: mailto:[EMAIL PROTECTED]
> > -Original Message-
> > From: zhang_sdu [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 28, 2001 8:03 AM
> > To: Bill Crum
> > Cc: Karim Yaghmour; Guilherme Nelson F De Souza; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: [rtl] RTAI and RTLinux
> >
> >
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | 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 " | 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 " | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

RE: VIRUS ALERT was:[rtl] RTAI and RTLinux

[Thomas Frasher]

There is a patch to the outlook to prevent any attachements that are deemed
infected.  it works.  I don't even get to see the attachments that are
scunged.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Dresner, Norman A.
Sent: Wednesday, March 28, 2001 7:58 AM
To: 'RTLinux'
Subject: FW: VIRUS ALERT was:[rtl] RTAI and RTLinux


This message just came in with an attachment called Emanuelle.exe that
Norton Anti-Virus said was a virus.

While I think that attachments are a useful part of our mailing list, we've
got to start filtering them to kill all .exe, .com, .vbs, ... that will
execute on a Windows system -- which is my primary mail client in all
locations.

Norman Dresner
Fellow Systems Engineer & SGI Laboratory Administrator
Radar Systems Engineering Department
Electronic Systems and Sensors Segment
Northrop Grumman Corporation
Baltimore-Washington International Airport
7323 Aviation Boulevard
Baltimore Maryland 21240

Voice:  (410) 993 - 2096Mornings; all-day voice-mail
(410) 969 - 8068Afternoons with answering machine
FAX:(410) 993 - 8084On-site
(410) 969 - 8068Afternoons; call first to arrange
E-Mail: Mornings:   mailto:[EMAIL PROTECTED]
Afternoons: mailto:[EMAIL PROTECTED]
> -Original Message-
> From: zhang_sdu [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 8:03 AM
> To:   Bill Crum
> Cc:   Karim Yaghmour; Guilherme Nelson F De Souza; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject:  Re: [rtl] RTAI and RTLinux
>
>
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | 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 " | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

FW: VIRUS ALERT was:[rtl] RTAI and RTLinux

[Dresner, Norman A.]

This message just came in with an attachment called Emanuelle.exe that
Norton Anti-Virus said was a virus.

While I think that attachments are a useful part of our mailing list, we've
got to start filtering them to kill all .exe, .com, .vbs, ... that will
execute on a Windows system -- which is my primary mail client in all
locations.

Norman Dresner
Fellow Systems Engineer & SGI Laboratory Administrator
Radar Systems Engineering Department
Electronic Systems and Sensors Segment
Northrop Grumman Corporation
Baltimore-Washington International Airport
7323 Aviation Boulevard
Baltimore Maryland 21240

Voice:  (410) 993 - 2096Mornings; all-day voice-mail
(410) 969 - 8068Afternoons with answering machine
FAX:(410) 993 - 8084On-site
(410) 969 - 8068Afternoons; call first to arrange
E-Mail: Mornings:   mailto:[EMAIL PROTECTED]
Afternoons: mailto:[EMAIL PROTECTED]
> -Original Message-
> From: zhang_sdu [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 8:03 AM
> To:   Bill Crum
> Cc:   Karim Yaghmour; Guilherme Nelson F De Souza; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject:  Re: [rtl] RTAI and RTLinux
> 
> 
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[zhang_sdu]

 Emanuel.exe

Re: [rtl] RTAI and RTLinux

[Stuart Hughes]

[EMAIL PROTECTED] wrote:

> Next month, when someone else from Lineo invents local variables or
> the letter "a", we will undoubtedly see yet another one of these strange
> episodes.

Bitch 

How about we all lighten up a little.

Regards, Stuart
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Ivan Martinez]

Let's solve this as gentlemen. Guns or swords?.

-- 
Ivan Martinez (Rodriguez)
Bch in Software Engineering - MSc student
http://www.geocities.com/ivan_m_r2/
"Got fabes?"
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Karim Yaghmour]

Hmm... Very interesting remarks :)

[EMAIL PROTECTED] wrote:
> Karim was also astounded to find that IBM had a remarkably
> similar product, and he apparently never looked at Oleg Subbotin's MS
> thesis in which he traced RTLinux threads or  Ismail Rippoli's
> RTLinux graphing tool (http://bernia.disca.upv.es/~iripoll/), or
> read my 1996 paper on tracing Linux file system behavior or ...

First I wasn't astounded by IBM's stuff, I've known for a long time
that AIX has had a tracing facility and so does SUN. This is nothing
new to me, FYI. As for Oleg Subbotin's and Ismail Rippoli's stuff, thank
you for the pointer, but then again I see no relation between this and my
remarks except trying to discredit me. As I've told you before, this
is called sophism in philosphy 101.

(By the way I'd really like to read Oleg's stuff, but I can't seem
to find it, anyone have a valid pointer ... thanks.)

I might also point out that LTT is not a product, it is a project.
There is a big difference between those two concepts. A product is
something you can sell, a project is something you contribute to.
This actually goes to show that my analysis is right, you view open-
source projects as something you can market, not something you can
provide expertise for. This is the same mind-set most Linux vendors
have. There is nothing wrong with it per-se, but there is something
wrong in your misleading the community to believe that you are truly
of open-source spirit.

> Shockingly, many of these projects use the same method of spooling data
> in a buffer and having a daemon empty the data -- in fact, somehow Linux has
> been doing this for syslog for many years.

That has never been my claim ...

Please do go to LTT's web site and go get the paper I presented at the
last annual Usenix conference as part of the main refreed track on LTT.
In it, you would see that I do not claim to have invented the data
collection methods I use, rather I emphasize on the fact that this
data had not been used in this manor before. I have read a couple of
your papers, I think you ought to read some of mine. Especially since
said paper was presented as part of one of the most important computer-
science conferences in the world.

> Next month, when someone else from Lineo invents local variables or
> the letter "a", we will undoubtedly see yet another one of these strange
> episodes.

I guess, my advice wasn't heard. In any case, it should be clear to any
reader that your statement is very harmfull to the open-source community's
image. But then again, you don't really care about that community, you
care about the possible revenus. So be it.

Best regards

Karim Yaghmour

===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Karim Yaghmour]

Hello Herman,

Don't worry, I'm not about to flame you :)

I do disagree with your appreciation of the situation, but I do
respect your point of view. I don't think there can be a comparison
between MS and RTAI; their goals, dynamics and finalities are
completely different. As for my "dead-end" claim, you are right, it
is pretty strong, but then again, it does reflect my opinion about
RTL in its current state. I don't pretend to be __neutral__ here,
though I do think that there are misconceptions about how RTAI came
to be, where it's going and how it's going there.

By the way, thanks for your HOWTO, I think it's a great starting
point for anyone wanting to do RT using open-source.

Best regards

Karim

Herman Bruyninckx wrote:
> Well, let me try (as a _neutral_ observer) to make this clear: there
> is a trade-off between (i) adding features that people (think they)
> need, and (ii) offering a system that is and remains as predictable as
> possible. The former is the Microsoft/RTAI/... way, the latter is
> Linux(kernel)/RTL/... way.
> ( Don't flame me for being over-simplistic :-) )
> There is a room for both parts of this spectrum.
> 
> > I applaud the wisdom of the RTAI guys for having recognized that RTL
> > was a dead-end
> ??Mmmm. Strong claim you make here :-)
> 
> --
> [EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87
> Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium
> Real Time and Embedded HOWTO:
>
> 
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/

-- 
===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Herman Bruyninckx]

On Fri, 8 Sep 2000, Karim Yaghmour wrote:

> I'm sorry to say this, but you got this all upside down. Paolo and
> all the other RTAI developers, for that matter, have been very keen to
> recognize the contributions of RTL. The contrary, though, is not
> true. RTL developers have strived very hard to demonstrate that RTAI
> "features" are, at best, trivial to implement and, at worst, technically
> deficient. Now, these guys can go on believing what they wish, and so
> can you, but from where I stand, I don't see any reason why anyone would
> choose RTL over RTAI, because of the feature-rich nature of RTAI. By this
> I mean that there are things possible in RTAI which aren't possible in RTL,
> least of them enabling a normal Linux process to become hard-RT, which,
> for me at least, deserves a Nobel by itself. 
Well, let me try (as a _neutral_ observer) to make this clear: there
is a trade-off between (i) adding features that people (think they)
need, and (ii) offering a system that is and remains as predictable as
possible. The former is the Microsoft/RTAI/... way, the latter is
Linux(kernel)/RTL/... way.
( Don't flame me for being over-simplistic :-) )
There is a room for both parts of this spectrum.

> I applaud the wisdom of the RTAI guys for having recognized that RTL
> was a dead-end 
??Mmmm. Strong claim you make here :-)

--
[EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87
Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium
Real Time and Embedded HOWTO:
   

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Michael Barabanov]

Karim,

Of course, I can not prove it, but at the time I put in the tracer support, I
was not aware of LTT's existence. I was trying to track down a timing problem
with in beta15, so I wrote this trace program that did help to solve the
problem.  Apart of "similar code" (note, I never saw any of LTT's
until your message about do_gettimeofday),
these two tools, as I see now, solve different purposes.

Michael.


Karim Yaghmour ([EMAIL PROTECTED]) wrote:
> Few were convinced, but I thought that Micheal's code was amazing and that the idea 
>was
> great, even though it seemed to be deja-vu. When I started working on the Linux
> Trace Toolkit, bringing LTT support for RTL was my ultimate dream. I thought that
> this would surely make it very clear that Linux could be used as an embedded/RT OS.
> Having been very busy developing LTT and attending every day obligations, I only
> got time to check LTT support for RTL in autumn '99, some time __after__ the first
> release. I went over to www.rtlinux.org and downloaded a copy of the latest RTL.
> To my dreadful surprise, someone had tried to instrument RTL. Not only that, but
> the code used to instrument RTL was severely familiar. No mention of my name could
> be found anywhere and no mention of the addition was made to any file. I only knew
> because I read the source code. This happened somewhere between beta 15 and beta 16
> in September '99, clearly two months after LTT's first release.
> 
> I was very disappointed by this. I thought to myself that if you take an idea from
> someone it would be the least of things to drop him an e-mail and tell him that you
> really liked what he did and that you might build on that. Least of things, you might
> ask him about what advice he might have about the problems he encountered so that you
> wouldn't fall in the same traps. You could even inquire about his desire to help out.
> It seems all of this was too much to ask.
> 
> Therefore, there is no surprise that I find it very credible when someone states that
> they've been copied by RTL and that they received no credit for their work. In
> Paolo's HAL case, this was blatant. There is no surprise either when I state that
> I am firmly against including any RTL code into the Linux source code. You've 
>misbehaved
> once, that's OK. RTAI will probably live on. Allowing such a mistake with Linux would
> be very harmfull to the open-source movement.
> 
> This is not the first time I post my views on your methods and motivations. On the
> last occasion, I was very flamy (accusing you of M$ behavior). Ensued a private
> discussion were I agreed to publicly apologize for my flaming so that we might
> continue the discussion at a more productive level. As I said above, the discussion
> didn't lead anywhere and I eventually abandoned it. This time though, my previous
> posting did not warrant any of your flak.
> 
> We probably will never agree on any of the things I'm pointing out and that's OK
> with me. One thing though, do refrain from spreading FUD about things you do not
> understand. If not for yourself, then for the negative image you are spreading about
> the open-source community.
> 
> Sincerely
> 
> Karim Yaghmour
> 
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Karim Yaghmour]

[EMAIL PROTECTED] wrote:
> 
> As usual, I will not reply to a completely untechnical  post on the newsgroup.
> However, I should point out that I admire the consistency with which Lineo 
>beneficiaries
> repeat the advertising slogan and forget to point out that they have a financial
> incentive.
> 

Your answer to my public posting was outright unwarranted, unjustified and completely
unacceptable. Even your base assumption is completely inaccurate and goes to show
that you are very much unaware of the personalities of the people your are referring
to and their motivations.

For the public record, I think it ought to be known that I have my opinions and
motivations which are not for sale even though I do offer my expertise commercially.
I accepted to develop LTT support for RTAI under Lineo sponsorship because we agreed
on the way the project should be done and on it's ultimate goal. This included making
sure the resulting code was available for everyone in the best quality it could be.
Lineo's initiative showed that they were inclined to fund open-source projects and
share their expertise while respecting the open-source movement. My duty, as an
open-source contributor, was to make sure that the project remained free. Having
secured this, I see no reason why I shouldn't offer my expertise to participate in
my project's development as I would do to participate in any other consulting activity
that I usually do. Ergo, your assumption is wrong. There was financial 
__compensation__,
but the incentive was that of an open-source enthusiast who wanted to add new features
to a project he very much enjoys working on.

As for your constant desire to point out that Lineo is contributing to RTAI, the
community should be aware that you yourself are very much a commercial entity making
money around RTL. Your patent __and__ the fact that most RTL code is copyrighted to
FSMLabs are the proof of this. I had privately raised questions about those two
items, but you never answered fully. You even went to the point of ridiculing me and
saying that I didn't have any weight to discuss such things since I hadn't contributed
anything to the open-source movement. You were forced to drop that line when I pointed
out that I was the author of the Linux Trace Toolkit, but you still weren't very
interested in clarifying things. Today, I must say that only one of the four questions
I asked remain unanswered. That is, I still have no explanation as to why you are
now the lead RTL developer and not M. Barbanov. I also inquired about the reason of
this switch, was it voluntary or "forced"? In a subquestion, I asked why Micheal's
name wasn't on the patent. If nothing else, this really intrigues me. Isn't he
the first to have implemented RTL? Doesn't he deserve to be on the patent. In any case,
we might never know, but going back to the patent and copyright thing, I think some
things should be made very clear to the open-source community. And in my opinion,
these two items can't be viewed separately.

Having copyrighted RTL code to FSMLabs, FSMLabs, as a commercial entity, and Victor
Yodaiken, as the CEO, can decide to commercially sell the source code to any private
entity. How is this? Well, they own the copyright (look at the file headers). This
means they can choose to distribute this in as many licensees as they which. Why?
Simple, RTL is under GPL and if any commercial entity wanted to patch their OS with it,
they'd suffer GPL contamination. Of course, this isn't definitive and the GPL hasn't
been tested enough to disprove this possibility, but it would be fair to say that no
commercial entity would take such a risk. But then why couldn't they simply do their
own simili-RTL for their own OS? Well, they can't ... Victor owns the patent to that
idea. Case closed.

This might be clear for you Victor, but very few people in the open-source community
see this and I think that a lot of people in the community would be outraged by this.
Frankly, I think your are doing a great disservice to the community by behaving so
recklessly towards the freedoms and obligations the GPL embodies. Lineo is clearly
a commercial entity, they've never tried to hide this. You, on the other hand, are
dancing on both feet between the open-source world and the commercial world, trying
to make everyone believe that you're the only reference and that all the others are
bad guys. In the open-source world, you claim to be the RTL benevolent dictator leading
the way for bringing real-time to Linux and in the commercial world, you trumpet your
company's "possessions" (RTL) and "powers" (the patent). Acting as an open-source 
leader,
you take the liberty to attack a commercial company on the grounds that they are
coercing developers into adopting RTAI while you are yourself a commercial entity who's
whole existence and financial future is based on the success of RTL.

Don't get me wrong, I didn't jump into the RTAI bandwagon out of the blue for no
reason. Actually, 

Re: [rtl] RTAI and RTLinux

[Karim Yaghmour]

us.
> 
>  Unfortunately, I think that *you* got it upside down. Because you
> see it as "Paolo and all the other RTAI developers ... have been very
> keen to recognize the contributions of RTL", but what Paolo really says
> is "Clearly RTAI has reinvented the wheel as it was already in use with
> DOS, using APIs found elswhere, but not in RTL".
>  I wish I had saved old emails from when Paolo's memory was actually
> keen and he admitted the contributions from RTLinux. It seems that a few
> things in life do have the power to erase our memories.
> 
>  Again, I apologize for this non-technical outburst. Maybe I was
> too naive to believe that the unification was possible and RT people
> could do the same that was done to Linux itself. After all, humans
> cannot overcome human nature.  ;-)
> 
>  Hats on for all of us.   ;-)
> 
> 
>   gnd
> 
> 
> 
> >From: Karim Yaghmour <[EMAIL PROTECTED]>
> >Subject: Re: [rtl] RTAI and RTLinux
> >Date: Fri, 8 Sep 2000 07:03:34 -0400
> >
> >
> >I'm sorry to say this, but you got this all upside down. Paolo and
> >all the other RTAI developers, for that matter, have been very keen to
> >recognize the contributions of RTL. The contrary, though, is not
> >true. RTL developers have strived very hard to demonstrate that RTAI
> >"features" are, at best, trivial to implement and, at worst, technically
> >deficient. Now, these guys can go on believing what they which, and so
> >can you, but from where I stand, I don't see any reason why anyone would
> >choose RTL over RTAI, because of the feature-rich nature of RTAI. By this
> >I mean that there are things possible in RTAI which aren't possible in RTL,
> >least of them enabling a normal Linux process to become hard-RT, which,
> >for me at least, deserves a Nobel by itself. Actually some of the
> >contributions of RTAI are so fundemental that it doesn't make sense to
> >see those as "small contributions". In that sense, having to state
> >the name of RTL as a mantra every time one writes new features for RTAI
> >would be like having to chant a song in recognition to the glories of Donald
> >Knuth every time you wrote an algorithm. Seriously, I applaud the wisdom of
> >the RTAI guys for having recognized that RTL was a dead-end and having the
> >guts to go against the wind, as you so well put it, to answer their true
> >calling, technical excellence.
> >
> >Hats off for the RTAI guys!
> >
> >Karim
> 
>-< G. N. DeSouza >-
>-< [EMAIL PROTECTED]>-
>--< http://rvl1.ecn.purdue.edu/~gnelson >--

-- 
===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Fri, Sep 08, 2000 at 12:50:50PM +0200, [EMAIL PROTECTED] wrote:
> 
> > The solution of having a cache on the RT side does not make the system
> > deterministic. What may become deterministic is that a yes/no result is 
> > in bounded time. But what remains is that the thread depending on this
> > system is now non-deterministic in operation.
> > 
> > This is not necessarily terrible, note that rtfifos to user processes
> > force a more limited type of nondeterminism -- but this is in a context where
> > a deterministic RT thread connects to a non-deterministc process.  
> 
> Dear Victor,
> 
> What do you mean "deterministic" exactly?
> 

Operation of the system does not depend on anything other than its inputs.


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Heinz . Haeberle]

I guess the whole discussion - I'm only a passive listener - can be reduced
to:

Yodaikens's (RTL) intention is to reduce the system to whatever is necessary
to
have a stable system. I understand the need of an easy and reduced api,
because
this normally results in a robust program and OS.

Paolo's (RTAI) intention is to implement things which are useful - and of
course
powerfull in some cases. And there is never a leak of new ideas. And to have
the
chance to use neat things (memory managemant, thread start in threads...)
doesn't
mean you HAVE TO USE IT!



In general I think there couldn't be a better way to develop RealtimeLinux
than the
situation is now. It's always a waist of energy to have - at least two -
different sytems,
but that is and was the way Linux is growing. Everything else is redmond.
I'm interesting
in RT Linux now for about 1 year and it is unbelievable how things are
growing there.
Unfortunately I have a job WITHOUT the chance to use it.

Heinz








   1stUp.com - Free the Web
   Get your free Internet access at http://www.1stUp.com
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Karim Yaghmour]

I'm sorry to say this, but you got this all upside down. Paolo and
all the other RTAI developers, for that matter, have been very keen to
recognize the contributions of RTL. The contrary, though, is not
true. RTL developers have strived very hard to demonstrate that RTAI
"features" are, at best, trivial to implement and, at worst, technically
deficient. Now, these guys can go on believing what they which, and so
can you, but from where I stand, I don't see any reason why anyone would
choose RTL over RTAI, because of the feature-rich nature of RTAI. By this
I mean that there are things possible in RTAI which aren't possible in RTL,
least of them enabling a normal Linux process to become hard-RT, which,
for me at least, deserves a Nobel by itself. Actually some of the
contributions of RTAI are so fundemental that it doesn't make sense to
see those as "small contributions". In that sense, having to state
the name of RTL as a mantra every time one writes new features for RTAI
would be like having to chant a song in recognition to the glories of Donald
Knuth every time you wrote an algorithm. Seriously, I applaud the wisdom of
the RTAI guys for having recognized that RTL was a dead-end and having the
guts to go against the wind, as you so well put it, to answer their true
calling, technical excellence.

Hats off for the RTAI guys!

Karim

Guilherme Nelson F De Souza wrote:
> 
>I can't agree with that. If you said that we make
> small changes to the wheel, so that it runs smoother,
> then I'd applaud your remark. Otherwise, it just serves
> to plagiarists in this and other fields of research to
> feel better about themselves. After all, adding small
> contributions to other people's work is the usual, ethical,
> and expected thing to do in research. As it is ethical
> and expected for one to recognize the origin of that work.
> 
>Anyway, if that were the case, that would explain why
> the Nobel Prize is not awarded to computer scientists.
> 
>   gnd
> 
> >Date: Thu, 7 Sep 2000 21:14:52 -0600
> >From: Cort Dougan <[EMAIL PROTECTED]>
> >Subject: Re: [rtl] RTAI and RTLinux
> >
> >} start awarding people for re-inventing the wheel.
> >
> >That is what we do in computer science, after all.
> >
> 
>-< G. N. DeSouza >-
>-< [EMAIL PROTECTED]>-
>--< http://rvl1.ecn.purdue.edu/~gnelson >--
> 
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/

-- 
===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[kissg]

> The solution of having a cache on the RT side does not make the system
> deterministic. What may become deterministic is that a yes/no result is 
> in bounded time. But what remains is that the thread depending on this
> system is now non-deterministic in operation.
> 
> This is not necessarily terrible, note that rtfifos to user processes
> force a more limited type of nondeterminism -- but this is in a context where
> a deterministic RT thread connects to a non-deterministc process.  

Dear Victor,

What do you mean "deterministic" exactly?

Regards

Gabor
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Fri, Sep 08, 2000 at 02:12:20AM +0100, Steve Papacharalambous wrote:
> [EMAIL PROTECTED] wrote:
> > All that said and done, however, since implementing a cache memory pool is the 
>work of maybe
> > an hour, at best, this discussion is more about philosophy of design than about 
>anything concrete.
> 
> Hi Victor,
> 
> For me this is less a matter of philosophy, rather it is a matter of
> necessity.  It's a normal design requirement to be able to dynamically
> create and destroy threads from within another thread.  The lack of this
> capability in RTLinux is a significant limitation,

I'm perhaps to dense to see this:

null_start(void *arg){  
int i = (int ) arg;
while(!die[i]){
  pthread_suspend_np(pthread_self());
  if(thread_function[i]) thread_function[i](i);
  thread_function[i] = 0;
  }
 return;
 }

module_init:
   pthread_t my_threads[NUMBER_OF_THREADS_WE_MIGHT_NEED];

for(i=0; i < NUMBER_OF_THREADS_WE_MIGHT_NEED; i++)
 pthread_creat(&my_threads[i],null_start, ... );



/* can be called even from a RT interrupt */
activate_a_thread(i,f){
if(!thread_function[i])thread_function[i] = f;
pthread_kill(my_threads[i], RTL_SIG_WAKEUP);
}


...

add some synchronization and ...

Am I missing something?



> 
> Best regards,
> 
> Steve
> 
> -- 
> 
> Lineo Industrial Solutions Group
> Visit http://www.lineo.com/
> 

-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Steve Papacharalambous]

[EMAIL PROTECTED] wrote:
> All that said and done, however, since implementing a cache memory pool is the work 
>of maybe
> an hour, at best, this discussion is more about philosophy of design than about 
>anything concrete.

Hi Victor,

For me this is less a matter of philosophy, rather it is a matter of
necessity.  It's a normal design requirement to be able to dynamically
create and destroy threads from within another thread.  The lack of this
capability in RTLinux is a significant limitation,

Best regards,

Steve

-- 

Lineo Industrial Solutions Group
Visit http://www.lineo.com/


-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Guilherme Nelson F De Souza]

>Date: Thu, 07 Sep 2000 14:23:55 +0200
>From: Paolo Mantegazza <[EMAIL PROTECTED]>
>Subject: Re: [rtl] RTAI and RTLinux
>
>...
>
>Once more RTAI has no problem in doing that. RTAI fifos were already
>based on the use of its srqs when RTL was still patching the kernel to
>protect Linux tasks queues to be used with fifos in real time.



   Am I wrong, or RTAI was based on RTL?  This sounds like someone here
is spitting in the wind. (Or, assuming it will make as much sense in 
english as it does in portuguese: one is spitting on the plate that 
oneself's eating from)



>...
>So I was just pleased to have them add, and copyright, what I think is
>an usefull service for RTAI.   ...


   "COPYRIGHT"??!! What kind of copyright? A GPL, I presume.
   But then again, copyright what??!! These things (ideas) are older than
the bible -- or maybe even older than the first draft of the book of 
Genesis.  ;-)


   Now I remember why I unsubscribe this list a year ago. 
   Isn't that about time we had one single RT-LINUX, or whatever
you want to call it?
   A year went by, and there are still threads like this one. Titled
"RTAI and RTLinux" or "RTAI vs. RTLinux".
   

   How about getting a Nobel Prize, a lot of people in this list will
get a Nobel Prize, alright. But first, the Nobel Foundation have to 
start awarding people for re-inventing the wheel.


 gnd






   -< G. N. DeSouza >-
   -< [EMAIL PROTECTED]>-
   --< http://rvl1.ecn.purdue.edu/~gnelson >--

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Thu, Sep 07, 2000 at 03:50:17PM -0400, Tony Mouawad wrote:
> I'm new to the RT world, but I'm curious... what significant challenges are
> there when working with dynamic memory and real time?  Just the term
> "dynamic" gives us an indication that the mechanism would be
> undeterministic... but what's worse case here?  Why is it impossible to have
> a "real time" dynamic memory manager?  At worst, nothing is "real time",


To illustrate:

Thread:
loop:
 if(get_a_buffer){
   wait for an interrupt
   copy data to buffer
   dispatch buffer
   }
  else try_to_recover();
  goto loop

Case 1: "get_a_buffer" may sometimes stall the thread
 Result: program may stop at any momement.
Case 2: "get_a_buffer" allocates from a pool that is used by other threads and 
 just returns failure if there is no free buffer.
 Result: program may fail at any input load depending on who else
 uses the buffer pool.
Case 3: "get_a_buffer" allocates data from a static pool used only by this thread
   and freed by the destination.
 Result: thread can handle sizeof(buffer_pool)/sizeof(buffer) outstanding
 requests. If a dispatched buffer is known to be freed within K time
 units and interrupts take less than K time units plus 
jitter+interrupt dispatch
 + copy time ...  then there will never be a out of buffer failure.

So it's a subtle difference with big implications.  In the case of  Steve 
Papacharalambous 
module, things are more complex since he essentially manages a cache of memory and 
replenishes this cache from Linux when the system is not busy. I think this is an
especially dangerous method since it makes out-of-memory failures  harder to find by 
testing. I'm in favor of:
 crank the input device up to full speed and see what happens
but to test our program above using a caching memory allocator we need
 crank the input device up to full speed, make Linux busy and
   also do something to exercise all other modules that may use 
   the memory allocator so that they use max memory.

All that said and done, however, since implementing a cache memory pool is the work of 
maybe
an hour, at best, this discussion is more about philosophy of design than about 
anything concrete.


-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Tony Mouawad]

I'm new to the RT world, but I'm curious... what significant challenges are
there when working with dynamic memory and real time?  Just the term
"dynamic" gives us an indication that the mechanism would be
undeterministic... but what's worse case here?  Why is it impossible to have
a "real time" dynamic memory manager?  At worst, nothing is "real time",
it's a matter of perception.  If I lived in a world where my timing
resolution is 1 sec at a time, then having a "dynamic" system ranging
between 0 and 0.99s would be perceived as "real time", keeping in mind
that we ignore any other "timing" details involved...  maybe I don't quite
understand the discussion but bottom line, what are the challenges
involved here???

- Tony



-Original Message-
From: Paolo Mantegazza <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
Date: Thursday, September 07, 2000 2:52 PM
Subject: Re: [rtl] RTAI and RTLinux


>[EMAIL PROTECTED] wrote:
>>
>> On Thu, Sep 07, 2000 at 06:58:48AM +0200, Paolo Mantegazza wrote:
>> > [EMAIL PROTECTED] wrote:
>> > - . do we want to bet how long will it take to see a real time
>> > memory manager in RTL?
>>
>> There is no such thing as a dynamic real time memory manager.
>
>In fact I was just betting there will be one in the future :-).
>
>> It's been some years since RTL has been available and we have
>> many times had this silly discussion.
>>
>> The code for a simple version is trivial.
>>
>>
>> Step 1: write some module code:
>> In Linux init:
>>ask for a soft RTL interrupt
>>install a handler
>>
>>  handler:
>>   read from request queue (could be a fifo)
>>   v = kmalloc( requested.space)
>>   *requested.result = v;
>>   pthread_wakeup_np(requested.thread);
>>
>> Step 2: write some RTL thread code.
>>
>> In  rtl  periodic thread;
>>
>>queue request.
>>pthread_kill(pthread_linux(),kmalloc_irq);
>>while( !request.result)
>>  pthread_wait_np();
>>
>> Step3 : receive Nobel Prize.
>
>Since you like joking, I feel invited to go on ;-).
>
>Once more RTAI has no problem in doing that. RTAI fifos were already
>based on the use of its srqs when RTL was still patching the kernel to
>protect Linux tasks queues to be used with fifos in real time.
>
>In fact we (I, Steve and Pierre) discussed a similar solution before
>they implemented theirs ideas, but they denied its usefulness because
>was too much not deterministic, and they needed a truly fast minimal
>latency dynamic memory manager for their applications.
>So I was just pleased to have them add, and copyright, what I think is
>an usefull service for RTAI. Recall that I support the idea that a reach
>toolbox of mechanisms enhances user politics implementation freedom.
>
>Note also that RTAI calls what you name soft interrupts as system
>requests and they are structured with two handlers, one for user and one
>for kernel space. So it could be simple for a supervisory user space
>process, acting as a user interface, to pre allocate memory in kernel
>space for a new stack of a to be launched rt_task, or a larger one onto
>which save an already in use stack, so that a real time task could be
>dynamically resumed on a larger stack if needed, and many other fancy
>things. However all those things were believed not satisfactory, because
>tightened to Linux, and thus miles away from a minimal latency memory
>management.
>
>Nonetheless RTAI exploits the idea of using an srq in relation to memory
>managment, but just for kfreeing kmalloced memory when tasks are
>deleted.
>
>Clearly I applied to have a Nobel Prize. They already promised me one
>when the euro will be worth .001 dollars, and it seems it will happen
>quite soon.
>
>Ciao, Paolo.
>-- [rtl] ---
>To unsubscribe:
>echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
>echo "unsubscribe rtl " | 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 " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Thu, Sep 07, 2000 at 02:23:55PM +0200, Paolo Mantegazza wrote:
> > There is no such thing as a dynamic real time memory manager.
> 
> In fact I was just betting there will be one in the future :-).

When we get infinite memory, sure.

> In fact we (I, Steve and Pierre) discussed a similar solution before
> they implemented theirs ideas, but they denied its usefulness because
> was too much not deterministic, and they needed a truly fast minimal
> latency dynamic memory manager for their applications.

The solution of having a cache on the RT side does not make the system
deterministic. What may become deterministic is that a yes/no result is 
in bounded time. But what remains is that the thread depending on this
system is now non-deterministic in operation.

This is not necessarily terrible, note that rtfifos to user processes
force a more limited type of nondeterminism -- but this is in a context where
a deterministic RT thread connects to a non-deterministc process.  


> Note also that RTAI calls what you name soft interrupts as system

I didn't make up the name "soft interrupts". 


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Paolo Mantegazza]

[EMAIL PROTECTED] wrote:
> 
> On Thu, Sep 07, 2000 at 06:58:48AM +0200, Paolo Mantegazza wrote:
> > [EMAIL PROTECTED] wrote:
> > - . do we want to bet how long will it take to see a real time
> > memory manager in RTL?
> 
> There is no such thing as a dynamic real time memory manager.

In fact I was just betting there will be one in the future :-).
 
> It's been some years since RTL has been available and we have
> many times had this silly discussion.
>
> The code for a simple version is trivial.
> 
> 
> Step 1: write some module code:
> In Linux init:
>ask for a soft RTL interrupt
>install a handler
> 
>  handler:
>   read from request queue (could be a fifo)
>   v = kmalloc( requested.space)
>   *requested.result = v;
>   pthread_wakeup_np(requested.thread);
> 
> Step 2: write some RTL thread code.
> 
> In  rtl  periodic thread;
> 
>queue request.
>pthread_kill(pthread_linux(),kmalloc_irq);
>while( !request.result)
>  pthread_wait_np();
> 
> Step3 : receive Nobel Prize.

Since you like joking, I feel invited to go on ;-).

Once more RTAI has no problem in doing that. RTAI fifos were already
based on the use of its srqs when RTL was still patching the kernel to
protect Linux tasks queues to be used with fifos in real time.

In fact we (I, Steve and Pierre) discussed a similar solution before
they implemented theirs ideas, but they denied its usefulness because
was too much not deterministic, and they needed a truly fast minimal
latency dynamic memory manager for their applications.
So I was just pleased to have them add, and copyright, what I think is
an usefull service for RTAI. Recall that I support the idea that a reach
toolbox of mechanisms enhances user politics implementation freedom.

Note also that RTAI calls what you name soft interrupts as system
requests and they are structured with two handlers, one for user and one
for kernel space. So it could be simple for a supervisory user space
process, acting as a user interface, to pre allocate memory in kernel
space for a new stack of a to be launched rt_task, or a larger one onto
which save an already in use stack, so that a real time task could be
dynamically resumed on a larger stack if needed, and many other fancy
things. However all those things were believed not satisfactory, because
tightened to Linux, and thus miles away from a minimal latency memory
management.

Nonetheless RTAI exploits the idea of using an srq in relation to memory
managment, but just for kfreeing kmalloced memory when tasks are
deleted.

Clearly I applied to have a Nobel Prize. They already promised me one
when the euro will be worth .001 dollars, and it seems it will happen
quite soon.

Ciao, Paolo.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Thu, Sep 07, 2000 at 06:58:48AM +0200, Paolo Mantegazza wrote:
> [EMAIL PROTECTED] wrote:
> - . do we want to bet how long will it take to see a real time
> memory manager in RTL?


There is no such thing as a dynamic real time memory manager.

It's been some years since RTL has been available and we have
many times had this silly discussion. 

The code for a simple version is trivial.
  

Step 1: write some module code:
In Linux init:
   ask for a soft RTL interrupt
   install a handler

 handler:
  read from request queue (could be a fifo)
  v = kmalloc( requested.space)
  *requested.result = v;
  pthread_wakeup_np(requested.thread);


Step 2: write some RTL thread code.

In  rtl  periodic thread;

   queue request.
   pthread_kill(pthread_linux(),kmalloc_irq);
   while( !request.result)
 pthread_wait_np();


Step3 : receive Nobel Prize.


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Paolo Mantegazza]

[EMAIL PROTECTED] wrote:

> 
> Providing a capability often also imposes a policy.  Once a memory allocator
> is part of the standard toolset, it may work its way into e.g. semaphore
> allocation and stack allocation.  An IPC mechanism that relies on extending
> the thread structure imposes that additional cost on code that may not
> need the IPC mechanism.  "Many features" is a policy as much as "few features".

Providing mechanisms absolutely does not impose any policy, it just
eases one in implementing the one he/she preferes. A reacher toolbox can
just help in carrying out the job.
Steve/Pierre's RTAI real time mem manager is linked by default in its
schedulers, it is not part of them. So if one wants it can link without
it. In any case there is no cost being paid by those that do not need
it.
With that I/we agree it is usefull, but I/we are not imposing anything
to anybody.
RTAI users are free to use the wealth of RTAI provided mechanisms to
implement their own policies, the way they want, without any loss of
performance. RTAI aims at their utmost freedom not at teaching them what
to do.
 
> For RTLinux, if someone wants to write a malloc module that calls down to
> Linux kmalloc (this is absolutely trivial), then there is no problem and we
> would most likely include it in the distribution. But basic RTLinux
> services do not use dynamic allocators so that there will be as
> few  surprises as possible.

The same is true for RTAI and proves that a real time mem manager does
no harm but just adds flexibility.

Standard Victor's behaviour, already seen in the past :-).
Roughly stated it goes this way:
- no, no, no is wrong;
- you must/should be better doing this and that;
- if somebody wants to contribute...;
- . do we want to bet how long will it take to see a real time
memory manager in RTL?

Ciao, Paolo.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Wed, Sep 06, 2000 at 12:16:44PM -0400, Karim Yaghmour wrote:
> 
> Even though some of your points are quite interesting, to me the real question
> is whether the RT subsystem should decide a policy or provide a capability. From
> what I see, some think that rt-mem-management is a bad policy, whereas others
> think that rt-mem-management is a very interesting capability.


Providing a capability often also imposes a policy.  Once a memory allocator
is part of the standard toolset, it may work its way into e.g. semaphore
allocation and stack allocation.  An IPC mechanism that relies on extending
the thread structure imposes that additional cost on code that may not
need the IPC mechanism.  "Many features" is a policy as much as "few features".

For RTLinux, if someone wants to write a malloc module that calls down to
Linux kmalloc (this is absolutely trivial), then there is no problem and we
would most likely include it in the distribution. But basic RTLinux
services do not use dynamic allocators so that there will be as
few  surprises as possible.

-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Karim Yaghmour]

Even though some of your points are quite interesting, to me the real question
is whether the RT subsystem should decide a policy or provide a capability. From
what I see, some think that rt-mem-management is a bad policy, whereas others
think that rt-mem-management is a very interesting capability.

Given the applications of RT systems and the underlying responsibilities of
their designers, both legal and moral, the system designers better know what
they are doing. This we will surely agree on. In that sense, there should be
very strict policies regarding possible behavior when designing and RT-based
system. That said, I'm not sure that limiting the capabilities of an RT system
designer will help make him/her a responsible human-being. Actually, it is likely
that if he/she feels limited, he/she will attempt to bypass/hack the current
capabilities to obtain the results he/she desires. In fact, chances are that
by providing a capability that has been designed and implemented by pros will
make RTL-systems safer since even though the designer might be inexperienced/
irresponsible, the system will know better.

To sum up, I assume we all are mature adults. Nobody needs to be told how
he/she should or should not design/program. Given the lead of an RTL-based system
that has rt-mem-management capability, I would very likely set a policy by which
rt-mem-management usage would require __Pontifical__ approval, but I'd nonetheless
appreciate the fact that it's available just in case ...

My 2 cents

David Olofson wrote:
> Well, I might have lost track somewhere, but if the pool is only available to
> RT tasks, and statically allocated, there is no resource balancing between RT
> and non RT - which would be one useful advantage if this could work. However,
> it cannot work, if the RT allocations are supposed to be hard RT.
> 
> Anyway, even if the pool and allocator is RTL only, designing applications this
> way makes it a lot harder to figure out how much memory you really need not to
> ever run out of it. Then again, memory is rather cheap these days, and you can
> usually have lots of it if you need, even in embeded systems, so it might pay
> off if it simplifies the rest of the design to great extent...
> 
> > Remember also that people seem to be thinking here in terms of a task
> > meeting its deadline with high precision every time.  That is fine for
> > the highest priority task, but if you have many task, the lower priority
> > tasks will have significant jitter.   Again, only a problem if you don't
> > take this into account in the design.
> 
> Indeed, but the lower prio tasks (if any at all!) usually don't deal with that
> critical stuff - having the output data ready before the deadline is all that
> matters, since the actual timing is managed by the highest prio task, or in
> hardware. That is, jitter is not a big and complex problem in a correct design.
> 
> Running out of memory OTOH, being forced to wait until some other task
> releases some, may well stall your task long enough to miss the deadline
> several times over. And if you have more than two or three tasks doing dynamic
> allocation, there's no realistic way of defining the worst case latency.
> 
> David Olofson
>  Programmer
>  Reologica Instruments AB
>  [EMAIL PROTECTED]
> 
> ..- M u C o S . .- David Olofson --.
> |   A Free/Open Multimedia   | | Audio Hacker |
> |  Plugin and Integration Standard   | |Linux Advocate|
> `> http://www.linuxdj.com/mucos -' | Open Source Advocate |
> ..- A u d i a l i t y . |Singer|
> |  Rock Solid Low Latency Signal Processing  | |  Songwriter  |
> `---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/

-- 
===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[David Olofson]

Wed, 06 Sep 2000 Stuart Hughes wrote:
> [EMAIL PROTECTED] wrote:
> > 
> > On Tue, Sep 05, 2000 at 10:18:25AM -0700, David Schleef wrote:
> > > I don't think that "running out of memory" and "running out of CPU
> > > time" are fundamentally different things.  It's just that with a
> > > memory allocator, you are notified of a lack of resources and can
> > > do something graceful instead of locking the machine.
> > 
> > Sure. But I think there is a significant difference between:
> >   1. At startup time, allocate N buffers for a pool
> >  for a particular purpose and have an allocate/free
> >  routine.
> > and
> >   2. Maintain a general purpose buffer pool with unknown
> >  size and many users.
> > 
> >
> 
> Hi Victor,
> 
> I think the big misunderstanding is that the pool of memory is only
> available to real-time tasks.

Well, I might have lost track somewhere, but if the pool is only available to
RT tasks, and statically allocated, there is no resource balancing between RT
and non RT - which would be one useful advantage if this could work. However,
it cannot work, if the RT allocations are supposed to be hard RT.

Anyway, even if the pool and allocator is RTL only, designing applications this
way makes it a lot harder to figure out how much memory you really need not to
ever run out of it. Then again, memory is rather cheap these days, and you can
usually have lots of it if you need, even in embeded systems, so it might pay
off if it simplifies the rest of the design to great extent...

> Remember also that people seem to be thinking here in terms of a task
> meeting its deadline with high precision every time.  That is fine for
> the highest priority task, but if you have many task, the lower priority
> tasks will have significant jitter.   Again, only a problem if you don't
> take this into account in the design.

Indeed, but the lower prio tasks (if any at all!) usually don't deal with that
critical stuff - having the output data ready before the deadline is all that
matters, since the actual timing is managed by the highest prio task, or in
hardware. That is, jitter is not a big and complex problem in a correct design.

Running out of memory OTOH, being forced to wait until some other task
releases some, may well stall your task long enough to miss the deadline
several times over. And if you have more than two or three tasks doing dynamic
allocation, there's no realistic way of defining the worst case latency.


David Olofson
 Programmer
 Reologica Instruments AB
 [EMAIL PROTECTED]

..- M u C o S . .- David Olofson --.
|   A Free/Open Multimedia   | | Audio Hacker |
|  Plugin and Integration Standard   | |Linux Advocate|
`> http://www.linuxdj.com/mucos -' | Open Source Advocate |
..- A u d i a l i t y . |Singer|
|  Rock Solid Low Latency Signal Processing  | |  Songwriter  |
`---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Wed, Sep 06, 2000 at 07:49:45AM +0100, Stuart Hughes wrote:
> I think the big misunderstanding is that the pool of memory is only
> available to real-time tasks.  This means that a design can be made

I agree with David Olofson here.


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[David Olofson]

Tue, 05 Sep 2000 David Schleef wrote:
> On Tue, Sep 05, 2000 at 05:05:56PM +0200, David Olofson wrote:
> > Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote:
> > > > > Let's say I have N message buffers in a pool. What if
> > > > > there is no more free buffer?
> > > > 
> > > > Then the design for your hard real
> > > > time system was wrong :-)
> > > 
> > > Or system reached its limits.
> > 
> > Yep, and the only options are a) redesign and b) upgrading the hardware.
> > 
> > > It depends on your possibilities and intentions.
> > > What if amount of incoming data is unpredictable but you have
> > > to process at most as you can with a limited hardware?
> > 
> > That's a kind of *soft* real time system, which is not really what RTL is
> > intended for. (Although the input->"some kind of output" latency could have a
> > hard RT requirement - but the memory allocation would still be soft RT.) You
> > can't optimize a single API for both hard and soft RT, at least not without
> > making it a major PITA to use if you want hard RT, so IMHO, it's a very good
> > idea not to mix these two kinds of systems up when discussing APIs.
> 
> I don't think that "running out of memory" and "running out of CPU
> time" are fundamentally different things.  It's just that with a
> memory allocator, you are notified of a lack of resources and can
> do something graceful instead of locking the machine.

Yes indeed; but still, if either of these things happen, you don't have a hard
RT system. Hard RT systems shouldn't have to worry about missed deadlines OR
running out of memory (or any other resources), as they have already failed if
they ever get into that situation.

Or; it's a good idea to handle every possible error condition nicely (within
reasonable limits!) as that makes debugging a lot easier, and it *might* save a
buggy hard RT system a few times, until the effect of the bug coincides with a
critical situation. And, as hard RT actually isn't in real life, improving the
statistics is a good thing. However, I believe *designing* around that
philosophy will result in serious problems sooner or later.

A general rule of all kinds of programming:

Fix design problems as you find them - don't burry them in code.


David Olofson
 Programmer
 Reologica Instruments AB
 [EMAIL PROTECTED]

..- M u C o S . .- David Olofson --.
|   A Free/Open Multimedia   | | Audio Hacker |
|  Plugin and Integration Standard   | |Linux Advocate|
`> http://www.linuxdj.com/mucos -' | Open Source Advocate |
..- A u d i a l i t y . |Singer|
|  Rock Solid Low Latency Signal Processing  | |  Songwriter  |
`---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[David Olofson]

Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote:
> On Tue, Sep 05, 2000 at 10:18:25AM -0700, David Schleef wrote:
> > I don't think that "running out of memory" and "running out of CPU
> > time" are fundamentally different things.  It's just that with a
> > memory allocator, you are notified of a lack of resources and can
> > do something graceful instead of locking the machine.
> 
> Sure. But I think there is a significant difference between:
>   1. At startup time, allocate N buffers for a pool 
>  for a particular purpose and have an allocate/free
>  routine.
> and 
>   2. Maintain a general purpose buffer pool with unknown
>  size and many users.

Exactly, and it's really all about defining what can happen in a system under
any likely or unlikely conditions. For 1. this is (usually) very easy, while you
have to take tons of code interacting in complex ways in account to figure out
how 2. will behave.


David Olofson
 Programmer
 Reologica Instruments AB
 [EMAIL PROTECTED]

..- M u C o S . .- David Olofson --.
|   A Free/Open Multimedia   | | Audio Hacker |
|  Plugin and Integration Standard   | |Linux Advocate|
`> http://www.linuxdj.com/mucos -' | Open Source Advocate |
..- A u d i a l i t y . |Singer|
|  Rock Solid Low Latency Signal Processing  | |  Songwriter  |
`---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Stuart Hughes]

[EMAIL PROTECTED] wrote:
> 
> On Tue, Sep 05, 2000 at 10:18:25AM -0700, David Schleef wrote:
> > I don't think that "running out of memory" and "running out of CPU
> > time" are fundamentally different things.  It's just that with a
> > memory allocator, you are notified of a lack of resources and can
> > do something graceful instead of locking the machine.
> 
> Sure. But I think there is a significant difference between:
>   1. At startup time, allocate N buffers for a pool
>  for a particular purpose and have an allocate/free
>  routine.
> and
>   2. Maintain a general purpose buffer pool with unknown
>  size and many users.
> 
>

Hi Victor,

I think the big misunderstanding is that the pool of memory is only
available to real-time tasks.  This means that a design can be made
based upon things you can control, whereas in a soft real-time system,
you are subject to the interference of things you cannot control (such
as a disk surge from an active web server for instance).  In the same
way you have to take care not to exceed the maximum frame time allocated
per task (CPU budget), you must also take care that you understand the
limitations of the memory allocator (e.g don't ask for too much too
quickly).

Remember also that people seem to be thinking here in terms of a task
meeting its deadline with high precision every time.  That is fine for
the highest priority task, but if you have many task, the lower priority
tasks will have significant jitter.   Again, only a problem if you don't
take this into account in the design.

Regards, Stuart
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Tue, Sep 05, 2000 at 10:18:25AM -0700, David Schleef wrote:
> I don't think that "running out of memory" and "running out of CPU
> time" are fundamentally different things.  It's just that with a
> memory allocator, you are notified of a lack of resources and can
> do something graceful instead of locking the machine.

Sure. But I think there is a significant difference between:
  1. At startup time, allocate N buffers for a pool 
 for a particular purpose and have an allocate/free
 routine.
and 
  2. Maintain a general purpose buffer pool with unknown
 size and many users.




-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[David Schleef]

On Tue, Sep 05, 2000 at 05:05:56PM +0200, David Olofson wrote:
> Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote:
> > > > Let's say I have N message buffers in a pool. What if
> > > > there is no more free buffer?
> > > 
> > > Then the design for your hard real
> > > time system was wrong :-)
> > 
> > Or system reached its limits.
> 
> Yep, and the only options are a) redesign and b) upgrading the hardware.
> 
> > It depends on your possibilities and intentions.
> > What if amount of incoming data is unpredictable but you have
> > to process at most as you can with a limited hardware?
> 
> That's a kind of *soft* real time system, which is not really what RTL is
> intended for. (Although the input->"some kind of output" latency could have a
> hard RT requirement - but the memory allocation would still be soft RT.) You
> can't optimize a single API for both hard and soft RT, at least not without
> making it a major PITA to use if you want hard RT, so IMHO, it's a very good
> idea not to mix these two kinds of systems up when discussing APIs.

I don't think that "running out of memory" and "running out of CPU
time" are fundamentally different things.  It's just that with a
memory allocator, you are notified of a lack of resources and can
do something graceful instead of locking the machine.




dave...

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[David Olofson]

Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote:
> > > Let's say I have N message buffers in a pool. What if
> > > there is no more free buffer?
> > 
> > Then the design for your hard real
> > time system was wrong :-)
> 
> Or system reached its limits.

Yep, and the only options are a) redesign and b) upgrading the hardware.

> It depends on your possibilities and intentions.
> What if amount of incoming data is unpredictable but you have
> to process at most as you can with a limited hardware?

That's a kind of *soft* real time system, which is not really what RTL is
intended for. (Although the input->"some kind of output" latency could have a
hard RT requirement - but the memory allocation would still be soft RT.) You
can't optimize a single API for both hard and soft RT, at least not without
making it a major PITA to use if you want hard RT, so IMHO, it's a very good
idea not to mix these two kinds of systems up when discussing APIs.

(The general problem of soft RT capable systems is that the dynamic allocation
and other stuff they provide makes it virtually impossible to write hard RT
applications, even if the kernel theoretically could provide the required
timing guarantees.)

> Then one can choice a stragegy of survival: throw away unprocessable
> data and do some clever. (Plan B: crash and reboot. ;-)

Well, with some systems, plan B and the "stragegy of survival" both actually
give the same result as plan C: miss a deadline and wreck some very expensive
machinery...

This basically applies to all control systems dealing with powerful and/or
sensitive machines, and particularly in situations where people may get hurt or
killed if the machines freak out. I'd say that a thoroughly tested RTL solution
could be appropriate at least for the less critical systems in this range, but
that doesn't go for *any* kind of soft RT system - and anything that shares
resources with non RT tasks in a similar way to a shared memory pool is
actually a soft RT system.


David Olofson
 Programmer
 Reologica Instruments AB
 [EMAIL PROTECTED]

..- M u C o S . .- David Olofson --.
|   A Free/Open Multimedia   | | Audio Hacker |
|  Plugin and Integration Standard   | |Linux Advocate|
`> http://www.linuxdj.com/mucos -' | Open Source Advocate |
..- A u d i a l i t y . |Singer|
|  Rock Solid Low Latency Signal Processing  | |  Songwriter  |
`---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[kissg]

> > Let's say I have N message buffers in a pool. What if
> > there is no more free buffer?
> 
> Then the design for your hard real
> time system was wrong :-)

Or system reached its limits. It depends on your possibilities and
intentions.
What if amount of incoming data is unpredictable but you have
to process at most as you can with a limited hardware?
Then one can choice a stragegy of survival: throw away unprocessable
data and do some clever. (Plan B: crash and reboot. ;-)

Gabor
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Fri, Sep 01, 2000 at 04:35:26PM +0200, [EMAIL PROTECTED] wrote:
> I don't agree.
> The world - where the program runs - is undeterministic.
> Program must adapt itself to various circumstances including lack of
> resources. Let's say I have N message buffers in a pool. What if
> there is no more free buffer?
> Running out of memory is just a situation what the task must handle
> if necessary. This is their problem, not yours.

For me, there is a critical difference between:
Spec 1: If there are no more than N events every K time units the 
system will never drop data.  
and
Spec 2: If total system memory demands allows, the system will never
drop data ...

If you allocate memory from a shared dynamic pool with open 
access to that pool, then any user of system resources, or any shifts 
in even the timing of the the non-RT portion of your total system may
cause failures. 

Running out of memory is tough enough in the non-RT domain. Linux kernel
list features endless discussions on how to keep the Linux kernel floating
when there is no more space. I think it all comes down to the specification of
the system. If non-deterministic failures are ok, then dynamic memory allocation
is ok. But if non-deterministic failures are ok, why not run in the Linux domain
anyways?


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Rus V. Brushkoff]

On Thu, 31 Aug 2000, Pierre Cloutier wrote:

: I switched to RTAI many moons ago when I finally understood Victor's ego
: was bigger than everest.

Time to read Carlos Castaneda.

: 
: 

Rus

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Bernhard Kuhn]

[EMAIL PROTECTED] wrote:

> Let's say I have N message buffers in a pool. What if
> there is no more free buffer?

Then the design for your hard real
time system was wrong :-)

Bernhard
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[kissg]

>  For what it is worth. Steve P. sent me a perfectly polite and 
>  useful explanation of how his memory allocator works and how it 
>  returns a failure instead of suspending when memory is exhausted. 
> 
>  I do continue to think that RT software should be simple and 
>  not rely on dynamic allocation of resources -- since this is not
>  compatible with determinism.  

I don't agree.
The world - where the program runs - is undeterministic.
Program must adapt itself to various circumstances including lack of
resources. Let's say I have N message buffers in a pool. What if
there is no more free buffer?
Running out of memory is just a situation what the task must handle
if necessary. This is their problem, not yours.

Regards

Gabor
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

RE: [rtl] RTAI and RTLinux

[Chris Clark]

-Original Message-
From:   [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, August 31, 2000 9:38 PM
To: Herman Bruyninckx
Cc: Paolo Mantegazza; [EMAIL PROTECTED]
Subject:Re: [rtl] RTAI and RTLinux

On Thu, Aug 31, 2000 at 05:18:35PM +0200, Herman Bruyninckx wrote:
> Another thing: if Victor is right about the fact that POSIX doesn't
> specify which signals can or should be used, then (i) we cannot blame
> him for using this option, (ii) the ``error'' lies with the POSIX

This is not an error -- it would be an error to fix a set of 
signals that would be presumed to all that are needed in any
 systems. POSIX defines a core set of signals that must be implemented and
an API.  BTW the RT signals are merely defined by a range. The
implementation is required to provide MAX and MIN definitions but POSIX
at least does not presume to tell us how big this range must be.


But POSIX does require that the range is at least 8. How big is the range in RTLinux 
and RTAI?
Chris
-oOo-
Chris Clark
LynuxWorks SA
email : [EMAIL PROTECTED]
web: www.lynuxworks.com
-oOo-

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Thu, Aug 31, 2000 at 11:13:54PM -0400, Pierre Cloutier wrote:
> I switched to RTAI many moons ago when I finally understood Victor's ego
> was bigger than everest.

Yet your website advertises a RTLinux project.  How curious.

In any event,  despite my vast ego, I really would appreciate it if we
could forgo another round of these ill-mannered and rather peculiar
discussions of my personality.
If you have a question, if you have a critique of how RTLinux works,
if you have a technical comment,
if you have a suggestion about anything from API to 
business model to proper compiler, that's fine.  Otherwise, please go
away.

---
 For what it is worth. Steve P. sent me a perfectly polite and 
 useful explanation of how his memory allocator works and how it 
 returns a failure instead of suspending when memory is exhausted. 

 I do continue to think that RT software should be simple and 
 not rely on dynamic allocation of resources -- since this is not
 compatible with determinism.  

 This is an interesting and important technical topic and one that 
 would benefit from real data and cases. 


Todays contest: Who wrote ?
In a world of enormous and intricate interfaces, constantly
changing tools and languages and systems, and relentless pressure for more
of everything, one can lose sight of the basic principles
-- simplicity, clarity, generality -- that form the bedrock of good software.
-

best regards 
 Victor
 

-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Pierre Cloutier]

At 06:18 AM 31-08-00 -0600, [EMAIL PROTECTED] wrote:
>On Thu, Aug 31, 2000 at 11:18:34AM +0100, Trevor Woolven wrote:
>> [EMAIL PROTECTED] wrote:
>> I wasn't being critical just asking for information but I have to echo
Stuart
>> here, if you have some speed/determinism problems with Steve's pThreads
package
>> then I'd like to take a look at them if you don't mind.
>
>My understanding is that, for example, 
>there is dynamic memory allocation in Steve's package.


There goes Victor again. Dynamic memory allocation must be bad, and, of
course it is bad because Victor says so. Never mind how efficient the
algorithm is.
Don't even waist time to read the code. Real time programmers should
allocate all resources in init_module() and reboot their computers when
things go wrong.

I switched to RTAI many moons ago when I finally understood Victor's ego
was bigger than everest.

Regards

Pierre Cloutier  
___

Pierre Cloutier  
Tel: (450)-659-9186
Fax: (450)-659-0014
POSEIDON CONTROLS INC
___

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

OT: RE: [rtl] RTAI and RTLinux

[Stephen D. Cohen]

Gang,

This is horribly and completely off topic, but I simply can not
resist.

> However, the discussion reminds me of some other holy wars (KDE-GNOME;
> NT-Linux; vi(m)-emacs; ...), which means that they focus on the
> differences, instead of on the commonalities. I would say the current
> POSIX-efforts of both projects bring them closer together again. After
> all, the major aim of POSIX was to bring ``simplicity, coherence,
> programmer familiarity'', wasn't it? :-)

What holy wars?  KDE, Linux and emacs: anything less would be
uncivilized. Was there ever any question?

Regards,

Steve

P.S. I like RTL as well, but then I haven't spent that much time with RTAI.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Thu, Aug 31, 2000 at 05:18:35PM +0200, Herman Bruyninckx wrote:
> Another thing: if Victor is right about the fact that POSIX doesn't
> specify which signals can or should be used, then (i) we cannot blame
> him for using this option, (ii) the ``error'' lies with the POSIX

This is not an error -- it would be an error to fix a set of 
signals that would be presumed to all that are needed in any
 systems. POSIX defines a core set of signals that must be implemented and
an API.  BTW the RT signals are merely defined by a range. The
implementation is required to provide MAX and MIN definitions but POSIX
at least does not presume to tell us how big this range must be.

-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Herman Bruyninckx]

> [EMAIL PROTECTED] wrote:
[ about RTLinux's POSIX compliance...]

On Thu, 31 Aug 2000, Paolo Mantegazza wrote:
[ about RTAI's POSIX compliance...]
> Apart from the fact that Steve's package cannot run with RTL, but only
> with RTAI, from my limited tests experience with Steve's POSIX the above
> seems a quite unfair statement.
> In fact thank to Steve's package RTAI has POSIX, for those that needs
> and wants to use it, with as much determinism as RTL, along with
> "simplicity, coherence, programmer familiarity", to say the least.

This thread is very interesting: under ``pressure'' of the news group
both Victor and Paolo seem to release much more information than I
could find on the webpages or in the source of both real-time Linux
forks :-)

However, the discussion reminds me of some other holy wars (KDE-GNOME;
NT-Linux; vi(m)-emacs; ...), which means that they focus on the
differences, instead of on the commonalities. I would say the current
POSIX-efforts of both projects bring them closer together again. After
all, the major aim of POSIX was to bring ``simplicity, coherence,
programmer familiarity'', wasn't it? :-)

But do these POSIX efforts achieve what the common API initiative
wanted to achieve in the first place, or is this something completely
different?

Another thing: if Victor is right about the fact that POSIX doesn't
specify which signals can or should be used, then (i) we cannot blame
him for using this option, (ii) the ``error'' lies with the POSIX
organisation, (iii) both RTAI and RTLinux are POSIX compliant.
Or am I overlooking some facts here...

--
[EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87
Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium
Real Time and Embedded HOWTO:
   

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Steve Papacharalambous]

[EMAIL PROTECTED] wrote:
> 
> On Thu, Aug 31, 2000 at 11:18:34AM +0100, Trevor Woolven wrote:
> > [EMAIL PROTECTED] wrote:
> > I wasn't being critical just asking for information but I have to echo Stuart
> > here, if you have some speed/determinism problems with Steve's pThreads package
> > then I'd like to take a look at them if you don't mind.
> 
> My understanding is that, for example,
> there is dynamic memory allocation in Steve's package.
> 

Hi Victor,

You're correct, there is dynamic memory allocation in the pthreads
package, but it makes use of pre-allocated chunks of memory during the
real time phases.  These chunks of memory are replenished and/or
released when the real time components are inactive, and so the impact
on speed and determinism is minimal.  There are no calls made to
allocate or deallocate memory from the Linux kernel during real time
operation,

Best regards,

Steve

-- 

Lineo Industrial Solutions Group
Visit http://www.lineo.com/


-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Stuart Hughes]

Hi Victor,

The package mentioned below is portable, it contains fifos and other
IPC's, but is is not Steve's pthreads package.

Regards, Stuart



[EMAIL PROTECTED] wrote:
> 
> On Thu, Aug 31, 2000 at 12:52:58PM +0200, Paolo Mantegazza wrote:
> > Apart from the fact that Steve's package cannot run with RTL, but only
> > with RTAI, from my limited tests experience with Steve's POSIX the above
> 
> Stuart?
> 
>   |
>   |From: Stuart Hughes <[EMAIL PROTECTED]>
>   |Organization: zentropix
>   |X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre8 i686)
>   |X-Accept-Language: en
>   |MIME-Version: 1.0
>   |To: [EMAIL PROTECTED]
>   |CC: Gusa <[EMAIL PROTECTED]>, RTL <[EMAIL PROTECTED]>
>   |Subject: Re: [rtl] SEMAPHORE MODULE =?iso-8859-1?Q?DON=B4T?= COMPILE
>   |References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
><[EMAIL PROTECTED]>
>   |Content-Type: text/plain; charset=iso-8859-1
>   |Content-Transfer-Encoding: 8bit
>   |Sender: [EMAIL PROTECTED]
>   |Precedence: bulk
>   |Status: RO
>   |Content-Length: 2970
>   |Lines: 88
>   |
>   |Hi Victor,
>   |
>   |That's correct, the portable fifos/semaphores/mailboxes can be found at
>   |http://www.zentropix.com/products/download.html by selecting
>   |rtai_rtl_fifos-04.tar.gz
>   |Please note that I have not tested this since RTLinux 2.0 or RTAI 1.0.
>   |Please let me know if you have any changes you want to go in.
>   |
>   |Regards, Stuart
>   |
>   |
>   |
>   |
>   |--
>   |-
>   |Victor Yodaiken
>   |Finite State Machine Labs: The RTLinux Company.
>   | www.fsmlabs.com  www.rtlinux.com
>   |
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | 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 " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Thu, Aug 31, 2000 at 12:52:58PM +0200, Paolo Mantegazza wrote:
> Apart from the fact that Steve's package cannot run with RTL, but only
> with RTAI, from my limited tests experience with Steve's POSIX the above


Stuart?

  |
  |From: Stuart Hughes <[EMAIL PROTECTED]>
  |Organization: zentropix
  |X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre8 i686)
  |X-Accept-Language: en
  |MIME-Version: 1.0
  |To: [EMAIL PROTECTED]
  |CC: Gusa <[EMAIL PROTECTED]>, RTL <[EMAIL PROTECTED]>
  |Subject: Re: [rtl] SEMAPHORE MODULE =?iso-8859-1?Q?DON=B4T?= COMPILE
  |References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
  |Content-Type: text/plain; charset=iso-8859-1
  |Content-Transfer-Encoding: 8bit
  |Sender: [EMAIL PROTECTED]
  |Precedence: bulk
  |Status: RO
  |Content-Length: 2970
  |Lines: 88
  |
  |Hi Victor,
  |
  |That's correct, the portable fifos/semaphores/mailboxes can be found at
  |http://www.zentropix.com/products/download.html by selecting
  |rtai_rtl_fifos-04.tar.gz
  |Please note that I have not tested this since RTLinux 2.0 or RTAI 1.0. 
  |Please let me know if you have any changes you want to go in.
  |
  |Regards, Stuart
  |
  |
  |
  |
  |-- 
  |-
  |Victor Yodaiken 
  |Finite State Machine Labs: The RTLinux Company.
  | www.fsmlabs.com  www.rtlinux.com
  |
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Paolo Mantegazza]

[EMAIL PROTECTED] wrote:

> We follow POSIX PSE51 for reasons of simplicity, coherence, programmer
> familiarity, and because there is a real standard, not a creature of
> any company.  POSIX is specified so that implementation extensions can
> be accomodated. For example, to reserve a RTLinux only processor in
> an SMP system, we have
>pthread_kill(pthread_linuxthread(),RTL_SIG_SUSPEND_LINUX );
> Of course, there is no signal RTL_SIG_SUSPEND_LINUX in the
> POSIX specifications and this code will fail on Chorus -- but  our
> goal is to make RTLinux programming easy, not to make RTLinux as slow
> and clumsy as Chorus. And the POSIX standard is designed to allow for
> such extensions.

In any case it remains not portable. Standards are a good things and
often people have to adhere to them, but IMHO saying that POSIX is
simple is wrong.

> As I have pointed out before, the purpose of Steve Papacharalambous'
> POSIX package is very much different from the purpose of our PSE51
> API -- even though we draw from the same base spec. Steve's package
> is great for people who want to port code from Chorus or Lynx or
> something to RTLinux.  But RTLinux is based on fundamentally
> different design than those systems and we are trying to make a
> convenient API for that design. So it misses the point to critique
> Steve's package for lack of speed/determinism 

Apart from the fact that Steve's package cannot run with RTL, but only
with RTAI, from my limited tests experience with Steve's POSIX the above
seems a quite unfair statement.
In fact thank to Steve's package RTAI has POSIX, for those that needs
and wants to use it, with as much determinism as RTL, along with
"simplicity, coherence, programmer familiarity", to say the least.

Ciao, Paolo.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Thu, Aug 31, 2000 at 11:18:34AM +0100, Trevor Woolven wrote:
> [EMAIL PROTECTED] wrote:
> I wasn't being critical just asking for information but I have to echo Stuart
> here, if you have some speed/determinism problems with Steve's pThreads package
> then I'd like to take a look at them if you don't mind.

My understanding is that, for example, 
there is dynamic memory allocation in Steve's package.

> 
> I personally seem to be a bit out of date here - how does PSE51 differ from
> 1003.1x ?

The POSIX 1003.13 standard defines 4 "environments" ranging from 
PSE51 (minimal realtime system) to PSE54 (multipurpose)
Linux itself is essentially PSE54 compliant -- with all the usual POSIX file
system  facilities etc. PSE51 defines a multi-threaded
 "single process" environment. So RTLinux defines a PSE51 system where
one of the threads, Linux, is a PSE54 system.  The enormous 
advantage of PSE51 is that it provides an accepted standard API that is
compatible with the RTLinux model and that can be adapted to our
programming environment without requiring us to add features that 
compromise the model and/or performance.
We have found that the pthreads model fits RTL surprisingly well:
"pthread_kill(pthread_linux_thread(), RTL_LINUX_IRQ_SIG+irq) "
to send an interrupt to Linux and  pthread_create to create a new
thread, and etc. 

IEEE standards can be purchased online from ieee.org. 


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Trevor Woolven]

[EMAIL PROTECTED] wrote:

> On Wed, Aug 30, 2000 at 03:18:23PM +0100, Trevor Woolven wrote:
> > BTW, can anyone *really* explain the point of non-portable extensions in a
> > (supposedly) portable standard? I'm not saying they're wrong but they don't
> > make sense (to me).
>
> We follow POSIX PSE51 for reasons of simplicity, coherence, programmer
> familiarity, and because there is a real standard, not a creature of
> any company.  POSIX is specified so that implementation extensions can
> be accomodated. For example, to reserve a RTLinux only processor in
> an SMP system, we have
>pthread_kill(pthread_linuxthread(),RTL_SIG_SUSPEND_LINUX );
> Of course, there is no signal RTL_SIG_SUSPEND_LINUX in the
> POSIX specifications and this code will fail on Chorus -- but  our
> goal is to make RTLinux programming easy, not to make RTLinux as slow
> and clumsy as Chorus. And the POSIX standard is designed to allow for
> such extensions.
>
> This is also an illustration of why we moved past the very simple V1
> API. In order to add this functionality to V1 we would have had to
> extend V1 and we decided that after a while V1-extended would be
> a horrible mess.  So between the choice of extending V1 and adopting
> a flexible, Pthreads API, we chose Pthreads.  The existence of PSE51,
> a POSIX standard that allowed us to do Pthreads without e.g. unix
> file system, made it possible.
>
> As I have pointed out before, the purpose of Steve Papacharalambous'
> POSIX package is very much different from the purpose of our PSE51
> API -- even though we draw from the same base spec. Steve's package
> is great for people who want to port code from Chorus or Lynx or
> something to RTLinux.  But RTLinux is based on fundamentally
> different design than those systems and we are trying to make a
> convenient API for that design. So it misses the point to critique
> Steve's package for lack of speed/determinism or our work for
> exposing the RTLinux design.
>

I wasn't being critical just asking for information but I have to echo Stuart
here, if you have some speed/determinism problems with Steve's pThreads package
then I'd like to take a look at them if you don't mind.

I personally seem to be a bit out of date here - how does PSE51 differ from
1003.1x ?

Thanks for your help
Trevor

>
> --
> -
> Victor Yodaiken
> Finite State Machine Labs: The RTLinux Company.
>  www.fsmlabs.com  www.rtlinux.com

--
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647 Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information



-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Michael Barabanov]

Stuart Hughes ([EMAIL PROTECTED]) wrote:
> [EMAIL PROTECTED] wrote:
> > As I have pointed out before, the purpose of Steve Papacharalambous'
> > POSIX package is very much different from the purpose of our PSE51
> > API -- even though we draw from the same base spec. Steve's package
> > is great for people who want to port code from Chorus or Lynx or
> > something to RTLinux.  
> 
> Indeed, very good for people porting real applications to RTAI.  I guess
> from the late addition of pthread_mutex_xxx and pthread_cond_xxx to
> RTLinux that you agree with his philosophy of using the Linuxthreads
> package as a template.

No, our philosophy is different, and we are not using Linuxthreads as a
template.  Rather than starting with Linuxthreads, we build our own
implementation.  We feel that this leaves us more freedom in choosing correct
(performance- and otherwise) design decisions. 

Michael.

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Wed, Aug 30, 2000 at 09:33:17PM +0100, Stuart Hughes wrote:
> I understand the reason for these non-portable extensions, but they
> unique features to RTLinux that lock-in users under the mask of
> perceived portability.

Stuart: I understand you disagree with our technical approach and you
work for a competitor, but please stop using such inflamatory language.


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Stuart Hughes]

[EMAIL PROTECTED] wrote:
> 
> On Wed, Aug 30, 2000 at 03:18:23PM +0100, Trevor Woolven wrote:
> > BTW, can anyone *really* explain the point of non-portable extensions in a
> > (supposedly) portable standard? I'm not saying they're wrong but they don't
> > make sense (to me).
> 
> We follow POSIX PSE51 for reasons of simplicity, coherence, programmer
> familiarity, and because there is a real standard, not a creature of
> any company.  POSIX is specified so that implementation extensions can
> be accomodated. For example, to reserve a RTLinux only processor in
> an SMP system, we have
>pthread_kill(pthread_linuxthread(),RTL_SIG_SUSPEND_LINUX );
> Of course, there is no signal RTL_SIG_SUSPEND_LINUX in the
> POSIX specifications and this code will fail on Chorus -- but  our
> goal is to make RTLinux programming easy, not to make RTLinux as slow
> and clumsy as Chorus. And the POSIX standard is designed to allow for
> such extensions.


I understand the reason for these non-portable extensions, but they
unique features to RTLinux that lock-in users under the mask of
perceived portability.


> As I have pointed out before, the purpose of Steve Papacharalambous'
> POSIX package is very much different from the purpose of our PSE51
> API -- even though we draw from the same base spec. Steve's package
> is great for people who want to port code from Chorus or Lynx or
> something to RTLinux.  

Indeed, very good for people porting real applications to RTAI.  I guess
from the late addition of pthread_mutex_xxx and pthread_cond_xxx to
RTLinux that you agree with his philosophy of using the Linuxthreads
package as a template.

> But RTLinux is based on fundamentally
> different design than those systems and we are trying to make a
> convenient API for that design. So it misses the point to critique
> Steve's package for lack of speed/determinism or our work for
> exposing the RTLinux design.

If you has some information that shows Steve's package is not
deterministic, I'd love to see it.

Regards, Stuart


-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Wed, Aug 30, 2000 at 03:18:23PM +0100, Trevor Woolven wrote:
> BTW, can anyone *really* explain the point of non-portable extensions in a
> (supposedly) portable standard? I'm not saying they're wrong but they don't
> make sense (to me).

We follow POSIX PSE51 for reasons of simplicity, coherence, programmer
familiarity, and because there is a real standard, not a creature of
any company.  POSIX is specified so that implementation extensions can
be accomodated. For example, to reserve a RTLinux only processor in 
an SMP system, we have 
   pthread_kill(pthread_linuxthread(),RTL_SIG_SUSPEND_LINUX );
Of course, there is no signal RTL_SIG_SUSPEND_LINUX in the
POSIX specifications and this code will fail on Chorus -- but  our
goal is to make RTLinux programming easy, not to make RTLinux as slow
and clumsy as Chorus. And the POSIX standard is designed to allow for
such extensions. 

This is also an illustration of why we moved past the very simple V1
API. In order to add this functionality to V1 we would have had to 
extend V1 and we decided that after a while V1-extended would be 
a horrible mess.  So between the choice of extending V1 and adopting
a flexible, Pthreads API, we chose Pthreads.  The existence of PSE51,
a POSIX standard that allowed us to do Pthreads without e.g. unix 
file system, made it possible.

As I have pointed out before, the purpose of Steve Papacharalambous'
POSIX package is very much different from the purpose of our PSE51
API -- even though we draw from the same base spec. Steve's package
is great for people who want to port code from Chorus or Lynx or 
something to RTLinux.  But RTLinux is based on fundamentally
different design than those systems and we are trying to make a 
convenient API for that design. So it misses the point to critique
Steve's package for lack of speed/determinism or our work for
exposing the RTLinux design.


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[yodaiken]

On Wed, Aug 30, 2000 at 01:23:01PM +0200, Herman Bruyninckx wrote:
> mean, if RTL comes out with version 3.0, how fast will the common API
> follow this new version? Or will it, by definition, be a greatest
> common divisor of the functionality of both forks?

RTL V3 has few API changes and what changes it has tend to be 
additions of POSIX calls.
 
-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Trevor Woolven]

Herman Bruyninckx wrote:

> On Wed, 30 Aug 2000, Trevor Woolven wrote:
>
> [... (in)compatibilities between RTL and RTAI...]
> > However, LineoISG (for whom I work - formerly called Zentropix) have
> > developed a Common API compatibility layer (it's actually a header
> > file) which allows users to write one set of code that can then be
> > used to run either RTAI or RTL.
> >
> > The general idea is that users can now take the same application
> > code and use whichever underlying Real-Time Linux they want. They
> > can also migrate between them as functionality and features
> > change/improve etc.
> How well does this common API follows the evolution of both forks? I
> mean, if RTL comes out with version 3.0, how fast will the common API
> follow this new version? Or will it, by definition, be a greatest
> common divisor of the functionality of both forks?
>

The Common API will be updated once we're happy that a release has
stabilized enough for us to do the work without wasting too much of it.
Obviously, we're susceptible to commercial pressure if customers want
the updates early.

>
> > We would like to see a *real* common API but that starts to get far
> > too political, so for the forseeable future we will maintain our
> > compatibility header and try to keep up with the changes.
> Shouldn't this *real* API be the POSIX-compliant one that RTL is
> trying hard to follow as far as reasonably possible? Or am I stating
> things a bit too simply here...
>

Well, if you look at the Common API it's very simple and the beauty of both
RTL and RTAI is that their 'core' APIs are so similar (for very good
reasons) and simple. The idea behind the Common API is to provide a small,
functional core to allow users to get the maximum, hard real-time
performance from their chosen Real-Time Linux without having to learn a
huge and unwieldy API. A small, well-chosen API that provides all the
necessary real time functionality is what we're after. Unfortunately, there
are subtle differences that (we thought) needed to be covered. Life would
be easier for all of us if the core APIs of RTAI and RTL could be merged
(yes, I know we've been here before!). 'Nuff said...

As to POSIX, we'd need to get a consensus from the providers of RTL and
RTAI on which POSIX calls to implement and which to ignore. I think it's
going to be extremely difficult for anyone to be fully POSIX-compliant (in
this area) due to the size and complexity of the standards (plus you have
to pay for them!). I understand that the standards do not mandate
everything in them (but I don't know which bits as I haven't read the
entire set). To my mind you are either compliant or you're not and
filling-up the grey area with a list of areas of non-compliance just
muddies the water further (and taxes my brain :-).

BTW, can anyone *really* explain the point of non-portable extensions in a
(supposedly) portable standard? I'm not saying they're wrong but they don't
make sense (to me).

>
> --
> [EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87
> Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium
> Real Time and Embedded HOWTO:
> 

--
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647 Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information



-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Herman Bruyninckx]

On Wed, 30 Aug 2000, Trevor Woolven wrote:

[... (in)compatibilities between RTL and RTAI...]
> However, LineoISG (for whom I work - formerly called Zentropix) have
> developed a Common API compatibility layer (it's actually a header
> file) which allows users to write one set of code that can then be
> used to run either RTAI or RTL. 
> 
> The general idea is that users can now take the same application
> code and use whichever underlying Real-Time Linux they want. They
> can also migrate between them as functionality and features
> change/improve etc. 
How well does this common API follows the evolution of both forks? I
mean, if RTL comes out with version 3.0, how fast will the common API
follow this new version? Or will it, by definition, be a greatest
common divisor of the functionality of both forks?

> We would like to see a *real* common API but that starts to get far
> too political, so for the forseeable future we will maintain our
> compatibility header and try to keep up with the changes.
Shouldn't this *real* API be the POSIX-compliant one that RTL is
trying hard to follow as far as reasonably possible? Or am I stating
things a bit too simply here...

--
[EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87
Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium
Real Time and Embedded HOWTO:


-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Trevor Woolven]

Karim Yaghmour wrote:

> This is actually quite interesting and goes to show that not all is clear
> about what RTAI is (no offence to Ivan, I'm just raising concerns).
>
> As others will fast point out, RTAI is an RT extension to Linux on it's own.
> It has very little to do with RTL in it's current form and doesn't have
> a pretence to it, in any case, even though it might have started from the
> same source.
>
> Therefore, RTAI features are RTAI features and RTL features are RTL features,
> no effort is made to "be compatible". Exception made of different independant
> projects who make an effort to be compatible with both (comedi is an example
> to this).
>
> In other words, your first assumption is wrong: RTAI is __NOT__ a compatible
> extension to RTL with extra features.
>

However, LineoISG (for whom I work - formerly called Zentropix) have developed a
Common
API compatibility layer (it's actually a header file) which allows users to write
one set of
code that can then be used to run either RTAI or RTL. This was produced after the
Real-Time
Linux workshop held in Vienna last December as most of the delegates seemed to
want one.

The general idea is that users can now take the same application code and use
whichever
underlying Real-Time Linux they want. They can also migrate between them as
functionality
and features change/improve etc. We would like to see a *real* common API but that
starts
to get far too political, so for the forseeable future we will maintain our
compatibility header and
try to keep up with the changes.

The Common API is available for free but you have to go to our website to get it,
(I hope that's not too much to ask :-)  http://www.lineoisg.com

We use the Common API  internally to support our customer base on both 'flavours'
of Real-Time Linux.

Hope this helps

Trev

>
> Hope this clear things a little for you (Ivan) and other readers out there.
>
> Karim
>
> Ivan Martinez wrote:
> >
> > Hello all:
> > I'm comparing RTAI to RTLinux and I just want to make you a couple of
> > questions. Please don't start fighting about which sytems is best!. It's
> > not about that.
> > I understood RTAI is a compatible extension of RTLinux with extra
> > features, right?. Is the extension made from every RTLinux version or
> > it's a different project-branch now?.
> > If it's an extension, how is compatibility kept?. Let's say RTLinux
> > guys decide to implement their own semaphores after RTAI. Because of
> > being the original project, they don't care about how things are already
> > implemented in RTAI, do they?. What happens then in RTAI?. Does it keep
> > both its original implementation and the new RTLinux one?.
> > Thank you, and please stay as friends ;-)
> > --
> > Ivan Martinez (Rodriguez)
> > Bch in Software Engineering - MSc student
> > http://www.geocities.com/ivan_m_r2/
> > "Got fabes?"
> > -- [rtl] ---
> > To unsubscribe:
> > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> > echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> > ---
> > For more information on Real-Time Linux see:
> > http://www.rtlinux.org/rtlinux/
>
> --
> ===
>  Karim Yaghmour
>[EMAIL PROTECTED]
>   Operating System Consultant
>  (Linux kernel, real-time and distributed systems)
> ===
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/

--
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647 Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information



-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and RTLinux

[Karim Yaghmour]

This is actually quite interesting and goes to show that not all is clear
about what RTAI is (no offence to Ivan, I'm just raising concerns).

As others will fast point out, RTAI is an RT extension to Linux on it's own.
It has very little to do with RTL in it's current form and doesn't have
a pretence to it, in any case, even though it might have started from the
same source.

Therefore, RTAI features are RTAI features and RTL features are RTL features,
no effort is made to "be compatible". Exception made of different independant
projects who make an effort to be compatible with both (comedi is an example
to this).

In other words, your first assumption is wrong: RTAI is __NOT__ a compatible
extension to RTL with extra features.

Hope this clear things a little for you (Ivan) and other readers out there.

Karim

Ivan Martinez wrote:
> 
> Hello all:
> I'm comparing RTAI to RTLinux and I just want to make you a couple of
> questions. Please don't start fighting about which sytems is best!. It's
> not about that.
> I understood RTAI is a compatible extension of RTLinux with extra
> features, right?. Is the extension made from every RTLinux version or
> it's a different project-branch now?.
> If it's an extension, how is compatibility kept?. Let's say RTLinux
> guys decide to implement their own semaphores after RTAI. Because of
> being the original project, they don't care about how things are already
> implemented in RTAI, do they?. What happens then in RTAI?. Does it keep
> both its original implementation and the new RTLinux one?.
> Thank you, and please stay as friends ;-)
> --
> Ivan Martinez (Rodriguez)
> Bch in Software Engineering - MSc student
> http://www.geocities.com/ivan_m_r2/
> "Got fabes?"
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/

-- 
===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

[rtl] RTAI and RTLinux

[Ivan Martinez]

Hello all:
I'm comparing RTAI to RTLinux and I just want to make you a couple of
questions. Please don't start fighting about which sytems is best!. It's
not about that.
I understood RTAI is a compatible extension of RTLinux with extra
features, right?. Is the extension made from every RTLinux version or
it's a different project-branch now?.
If it's an extension, how is compatibility kept?. Let's say RTLinux
guys decide to implement their own semaphores after RTAI. Because of
being the original project, they don't care about how things are already
implemented in RTAI, do they?. What happens then in RTAI?. Does it keep
both its original implementation and the new RTLinux one?.
Thank you, and please stay as friends ;-)
-- 
Ivan Martinez (Rodriguez)
Bch in Software Engineering - MSc student
http://www.geocities.com/ivan_m_r2/
"Got fabes?"
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] RTAI and rtlinux

[Trevor Woolven]

They're both very similar and use the same mechanism to achieve real
time performance. However, there are differences between them, so I
suggest you visit the two websites, download the latest versions and
take a look.

http://www.rtai.org/
http://www.rtlinux.org/rtlinux/

Regards

Trevor.

Zhixu Liu wrote:
> 
> What's the difference between RTAI and rtlinux (FSM Lab.)?
> 
> Zhixu
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/~rtlinux/

-- 
Trevor Woolven - Director of Customer Applications Engineering
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647 Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/

[rtl] RTAI and rtlinux

[Zhixu Liu]

What's the difference between RTAI and rtlinux (FSM Lab.)?

Zhixu
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/