[Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP

[Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP

[Ravid Baruch Naali]

Hello again,


Preface:

As of VxWorks 6.x vxworks implement RTP which is an implementation of
user space processes with real time capabilities, which of course
include an extended API, which from my testings I discovered that we do
not support yet.


Currently extending the VxWorks API is not in Xenomai task list, does it
have any demand?

If I'll take it as a my task, do we have any legal issues with using
Wind River's headers?


If any of my assumptions is false or if you have any comment/answers
please reply.


thanks

Ravid

-- 
Ravid Baruch Naali
ravidbn@domain.hid
+972 4 6732729
+972 52 5830021

Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP

[Philippe Gerum]

On Mon, 2007-09-03 at 17:05 +0300, Ravid Baruch Naali wrote:
> Hello again,
> 
> 
> Preface:
> 
> As of VxWorks 6.x vxworks implement RTP which is an implementation of
> user space processes with real time capabilities, which of course
> include an extended API, which from my testings I discovered that we do
> not support yet.
> 
> 
> Currently extending the VxWorks API is not in Xenomai task list, does it
> have any demand?
> 
> If I'll take it as a my task, do we have any legal issues with using
> Wind River's headers?

This matter is muddy; fair use, interoperability, and copyrights of
header files and/or their contents is a legal mess.

Our policy is simple: paste-copy of any portion of any proprietary
licensed header is unwanted and will be systematically rejected. You
need to implement your own header, defining what you need for satisfying
all the references within the emulator your are writing from scratch.

You should also explicitly mention in the copyright notice that the
resulting software is an emulator. We claim to mimick the original
software as correctly as possible, according to the API specs which have
been made publically available by the copyright holder of the original
work, with all the limitations inherent to such exercise. In any case,
we don't claim to produce a copy of the original software we only
emulate. In short, Xenomai is a Chameleon, not a clone.

> 
> 
> If any of my assumptions is false or if you have any comment/answers
> please reply.
> 
> 
> thanks
> 
> Ravid
> 
-- 
Philippe.

Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP

[Ravid Baruch Naali]

I imagined thats the policy.

But is it worth investing time in? or is there higher priority task I
can be assigned to?

 


Philippe Gerum wrote:

> On Mon, 2007-09-03 at 17:05 +0300, Ravid Baruch Naali wrote:
>   
>> Hello again,
>>
>>
>> Preface:
>>
>> As of VxWorks 6.x vxworks implement RTP which is an implementation of
>> user space processes with real time capabilities, which of course
>> include an extended API, which from my testings I discovered that we do
>> not support yet.
>>
>>
>> Currently extending the VxWorks API is not in Xenomai task list, does it
>> have any demand?
>>
>> If I'll take it as a my task, do we have any legal issues with using
>> Wind River's headers?
>>     
>
> This matter is muddy; fair use, interoperability, and copyrights of
> header files and/or their contents is a legal mess.
>
> Our policy is simple: paste-copy of any portion of any proprietary
> licensed header is unwanted and will be systematically rejected. You
> need to implement your own header, defining what you need for satisfying
> all the references within the emulator your are writing from scratch.
>
> You should also explicitly mention in the copyright notice that the
> resulting software is an emulator. We claim to mimick the original
> software as correctly as possible, according to the API specs which have
> been made publically available by the copyright holder of the original
> work, with all the limitations inherent to such exercise. In any case,
> we don't claim to produce a copy of the original software we only
> emulate. In short, Xenomai is a Chameleon, not a clone.
>
>   
>> If any of my assumptions is false or if you have any comment/answers
>> please reply.
>>
>>
>> thanks
>>
>> Ravid
>>
>>     


-- 
Ravid Baruch Naali
ravidbn@domain.hid
+972 4 6732729
+972 52 5830021

Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP

[Philippe Gerum]

On Tue, 2007-09-04 at 00:04 +0300, Ravid Baruch Naali wrote:
> I imagined thats the policy.
> 
> But is it worth investing time in? or is there higher priority task I
> can be assigned to?
> 

I don't think RTP is high priority for now.

Two other tasks would have a much more significant impact, both for
Xenomai users and developers.

1) Make Valgrind usable with Xenomai apps; of course without any
real-time guarantee anymore, but this would nevertheless plug a serious
hole in the development toolset available to users.

2) We do, certainly, definitely, desperately miss an automated way to
get performance charts for a few selected Xenomai tests, which would
allows us to conduct comparative analysis between versions, and find out
what's right or wrong with our changes.

For instance, we are currently maintaining seven architecture ports;
each time something changes in some part of Xenomai's generic code, we
have no freaking idea whether all archs benefit from such change, or if
at least no arch gets penalized by it. And the very same goes for the
interrupt pipeline, for which any hazardous change may generate adverse
effects on an even much larger scale. Let me put this bluntly: this
won't fly much longer; we are losing precious time getting rid of any
regression way after it has actually happened into the code, because we
cannot easily and routinely COMPARE how different versions behave. Aside
of this, we don't have any factual data regarding how Xenomai evolved
over time in terms of latency, code footprints and so on.

What we need is a simple automated way to a given test on any given
Xenomai version (actually a SVN commit number would be much better)
extracted from our repository, draw a few charts summing up the results,
and move those results to our website periodically or even as soon as
they are available. _This_ would help users to understand the current
trend and why we did some changes (or why we should not have done them),
and allow developers to pull the brake each time a serious regression is
visible from those charts.

Simple and easy:

TEST/x86: interrupt latency to kernel handler [latency -t2]

(latency in us)
^
|                                        x (XX us) <= Houston, we have a problem.
|      x (ZZ us)
|                                          
|                     x (YY us)
|                           
+--------------------------------------------------->
    commit#72  ...    commit#2004      commit#<any>
     (v2.0)              (v2.3)

Another test could analyse the task dispatch latency, another one the
code footprints in kernel space, and so on. Once this framework is
available, we would find the various hardware to run the tests on and
get the results from, that is not an issue anymore.

Besides, tackling this issue is quite a good way to have his feet wet
almost immediately with the Xenomai framework as a power user, and also
to get immediate reward for such work, since we would push its results
online routinely.

Please, somebody implement this, damnit! Or I'm going to rewrite the
entire Xenomai stack in Bourne shell with Java applets for speedups, so
you could not complain about bad latencies and unwanted overhead
anymore.

Thank you,

>  
> 
> 
> Philippe Gerum wrote:
> 
> > On Mon, 2007-09-03 at 17:05 +0300, Ravid Baruch Naali wrote:
> >   
> >> Hello again,
> >>
> >>
> >> Preface:
> >>
> >> As of VxWorks 6.x vxworks implement RTP which is an implementation of
> >> user space processes with real time capabilities, which of course
> >> include an extended API, which from my testings I discovered that we do
> >> not support yet.
> >>
> >>
> >> Currently extending the VxWorks API is not in Xenomai task list, does it
> >> have any demand?
> >>
> >> If I'll take it as a my task, do we have any legal issues with using
> >> Wind River's headers?
> >>     
> >
> > This matter is muddy; fair use, interoperability, and copyrights of
> > header files and/or their contents is a legal mess.
> >
> > Our policy is simple: paste-copy of any portion of any proprietary
> > licensed header is unwanted and will be systematically rejected. You
> > need to implement your own header, defining what you need for satisfying
> > all the references within the emulator your are writing from scratch.
> >
> > You should also explicitly mention in the copyright notice that the
> > resulting software is an emulator. We claim to mimick the original
> > software as correctly as possible, according to the API specs which have
> > been made publically available by the copyright holder of the original
> > work, with all the limitations inherent to such exercise. In any case,
> > we don't claim to produce a copy of the original software we only
> > emulate. In short, Xenomai is a Chameleon, not a clone.
> >
> >   
> >> If any of my assumptions is false or if you have any comment/answers
> >> please reply.
> >>
> >>
> >> thanks
> >>
> >> Ravid
> >>
> >>     
> 
> 
-- 
Philippe.

Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP

[Ravid Baruch Naali]

The automated chart seems exactly the thing for me (I have some testing
tools development experience).

I'll look into it and will soon send a initial design.


Of course any pinters/advice/suggestions will be highly appreciated.


Philippe Gerum wrote:

> On Tue, 2007-09-04 at 00:04 +0300, Ravid Baruch Naali wrote:
>   
>> I imagined thats the policy.
>>
>> But is it worth investing time in? or is there higher priority task I
>> can be assigned to?
>>
>>     
>
> I don't think RTP is high priority for now.
>
> Two other tasks would have a much more significant impact, both for
> Xenomai users and developers.
>
> 1) Make Valgrind usable with Xenomai apps; of course without any
> real-time guarantee anymore, but this would nevertheless plug a serious
> hole in the development toolset available to users.
>
> 2) We do, certainly, definitely, desperately miss an automated way to
> get performance charts for a few selected Xenomai tests, which would
> allows us to conduct comparative analysis between versions, and find out
> what's right or wrong with our changes.
>
> For instance, we are currently maintaining seven architecture ports;
> each time something changes in some part of Xenomai's generic code, we
> have no freaking idea whether all archs benefit from such change, or if
> at least no arch gets penalized by it. And the very same goes for the
> interrupt pipeline, for which any hazardous change may generate adverse
> effects on an even much larger scale. Let me put this bluntly: this
> won't fly much longer; we are losing precious time getting rid of any
> regression way after it has actually happened into the code, because we
> cannot easily and routinely COMPARE how different versions behave. Aside
> of this, we don't have any factual data regarding how Xenomai evolved
> over time in terms of latency, code footprints and so on.
>
> What we need is a simple automated way to a given test on any given
> Xenomai version (actually a SVN commit number would be much better)
> extracted from our repository, draw a few charts summing up the results,
> and move those results to our website periodically or even as soon as
> they are available. _This_ would help users to understand the current
> trend and why we did some changes (or why we should not have done them),
> and allow developers to pull the brake each time a serious regression is
> visible from those charts.
>
> Simple and easy:
>
> TEST/x86: interrupt latency to kernel handler [latency -t2]
>
> (latency in us)
> ^
> |                                        x (XX us) <= Houston, we have a problem.
> |      x (ZZ us)
> |                                          
> |                     x (YY us)
> |                           
> +--------------------------------------------------->
>     commit#72  ...    commit#2004      commit#<any>
>      (v2.0)              (v2.3)
>
> Another test could analyse the task dispatch latency, another one the
> code footprints in kernel space, and so on. Once this framework is
> available, we would find the various hardware to run the tests on and
> get the results from, that is not an issue anymore.
>
> Besides, tackling this issue is quite a good way to have his feet wet
> almost immediately with the Xenomai framework as a power user, and also
> to get immediate reward for such work, since we would push its results
> online routinely.
>
> Please, somebody implement this, damnit! Or I'm going to rewrite the
> entire Xenomai stack in Bourne shell with Java applets for speedups, so
> you could not complain about bad latencies and unwanted overhead
> anymore.
>
> Thank you,
>
>   
>>  
>>
>>
>> Philippe Gerum wrote:
>>
>>     
>>> On Mon, 2007-09-03 at 17:05 +0300, Ravid Baruch Naali wrote:
>>>   
>>>       
>>>> Hello again,
>>>>
>>>>
>>>> Preface:
>>>>
>>>> As of VxWorks 6.x vxworks implement RTP which is an implementation of
>>>> user space processes with real time capabilities, which of course
>>>> include an extended API, which from my testings I discovered that we do
>>>> not support yet.
>>>>
>>>>
>>>> Currently extending the VxWorks API is not in Xenomai task list, does it
>>>> have any demand?
>>>>
>>>> If I'll take it as a my task, do we have any legal issues with using
>>>> Wind River's headers?
>>>>     
>>>>         
>>> This matter is muddy; fair use, interoperability, and copyrights of
>>> header files and/or their contents is a legal mess.
>>>
>>> Our policy is simple: paste-copy of any portion of any proprietary
>>> licensed header is unwanted and will be systematically rejected. You
>>> need to implement your own header, defining what you need for satisfying
>>> all the references within the emulator your are writing from scratch.
>>>
>>> You should also explicitly mention in the copyright notice that the
>>> resulting software is an emulator. We claim to mimick the original
>>> software as correctly as possible, according to the API specs which have
>>> been made publically available by the copyright holder of the original
>>> work, with all the limitations inherent to such exercise. In any case,
>>> we don't claim to produce a copy of the original software we only
>>> emulate. In short, Xenomai is a Chameleon, not a clone.
>>>
>>>   
>>>       
>>>> If any of my assumptions is false or if you have any comment/answers
>>>> please reply.
>>>>
>>>>
>>>> thanks
>>>>
>>>> Ravid
>>>>
>>>>     
>>>>         
>>     


-- 
Ravid Baruch Naali
ravidbn@domain.hid
+972 4 6732729
+972 52 5830021

Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP

[Philippe Gerum]

On Tue, 2007-09-04 at 16:45 +0300, Ravid Baruch Naali wrote:
> The automated chart seems exactly the thing for me (I have some testing
> tools development experience).
> 
> I'll look into it and will soon send a initial design.
> 

Great, really. Please also take into account that when testing, we will
actually qualify a combo of the form [Xenomai commit x Adeos patch
release] each time. This should not change the basic principles of this
framework though.

> 
> Of course any pinters/advice/suggestions will be highly appreciated.
> 
> 
> Philippe Gerum wrote:
> 
> > On Tue, 2007-09-04 at 00:04 +0300, Ravid Baruch Naali wrote:
> >   
> >> I imagined thats the policy.
> >>
> >> But is it worth investing time in? or is there higher priority task I
> >> can be assigned to?
> >>
> >>     
> >
> > I don't think RTP is high priority for now.
> >
> > Two other tasks would have a much more significant impact, both for
> > Xenomai users and developers.
> >
> > 1) Make Valgrind usable with Xenomai apps; of course without any
> > real-time guarantee anymore, but this would nevertheless plug a serious
> > hole in the development toolset available to users.
> >
> > 2) We do, certainly, definitely, desperately miss an automated way to
> > get performance charts for a few selected Xenomai tests, which would
> > allows us to conduct comparative analysis between versions, and find out
> > what's right or wrong with our changes.
> >
> > For instance, we are currently maintaining seven architecture ports;
> > each time something changes in some part of Xenomai's generic code, we
> > have no freaking idea whether all archs benefit from such change, or if
> > at least no arch gets penalized by it. And the very same goes for the
> > interrupt pipeline, for which any hazardous change may generate adverse
> > effects on an even much larger scale. Let me put this bluntly: this
> > won't fly much longer; we are losing precious time getting rid of any
> > regression way after it has actually happened into the code, because we
> > cannot easily and routinely COMPARE how different versions behave. Aside
> > of this, we don't have any factual data regarding how Xenomai evolved
> > over time in terms of latency, code footprints and so on.
> >
> > What we need is a simple automated way to a given test on any given
> > Xenomai version (actually a SVN commit number would be much better)
> > extracted from our repository, draw a few charts summing up the results,
> > and move those results to our website periodically or even as soon as
> > they are available. _This_ would help users to understand the current
> > trend and why we did some changes (or why we should not have done them),
> > and allow developers to pull the brake each time a serious regression is
> > visible from those charts.
> >
> > Simple and easy:
> >
> > TEST/x86: interrupt latency to kernel handler [latency -t2]
> >
> > (latency in us)
> > ^
> > |                                        x (XX us) <= Houston, we have a problem.
> > |      x (ZZ us)
> > |                                          
> > |                     x (YY us)
> > |                           
> > +--------------------------------------------------->
> >     commit#72  ...    commit#2004      commit#<any>
> >      (v2.0)              (v2.3)
> >
> > Another test could analyse the task dispatch latency, another one the
> > code footprints in kernel space, and so on. Once this framework is
> > available, we would find the various hardware to run the tests on and
> > get the results from, that is not an issue anymore.
> >
> > Besides, tackling this issue is quite a good way to have his feet wet
> > almost immediately with the Xenomai framework as a power user, and also
> > to get immediate reward for such work, since we would push its results
> > online routinely.
> >
> > Please, somebody implement this, damnit! Or I'm going to rewrite the
> > entire Xenomai stack in Bourne shell with Java applets for speedups, so
> > you could not complain about bad latencies and unwanted overhead
> > anymore.
> >
> > Thank you,
> >
> >   
> >>  
> >>
> >>
> >> Philippe Gerum wrote:
> >>
> >>     
> >>> On Mon, 2007-09-03 at 17:05 +0300, Ravid Baruch Naali wrote:
> >>>   
> >>>       
> >>>> Hello again,
> >>>>
> >>>>
> >>>> Preface:
> >>>>
> >>>> As of VxWorks 6.x vxworks implement RTP which is an implementation of
> >>>> user space processes with real time capabilities, which of course
> >>>> include an extended API, which from my testings I discovered that we do
> >>>> not support yet.
> >>>>
> >>>>
> >>>> Currently extending the VxWorks API is not in Xenomai task list, does it
> >>>> have any demand?
> >>>>
> >>>> If I'll take it as a my task, do we have any legal issues with using
> >>>> Wind River's headers?
> >>>>     
> >>>>         
> >>> This matter is muddy; fair use, interoperability, and copyrights of
> >>> header files and/or their contents is a legal mess.
> >>>
> >>> Our policy is simple: paste-copy of any portion of any proprietary
> >>> licensed header is unwanted and will be systematically rejected. You
> >>> need to implement your own header, defining what you need for satisfying
> >>> all the references within the emulator your are writing from scratch.
> >>>
> >>> You should also explicitly mention in the copyright notice that the
> >>> resulting software is an emulator. We claim to mimick the original
> >>> software as correctly as possible, according to the API specs which have
> >>> been made publically available by the copyright holder of the original
> >>> work, with all the limitations inherent to such exercise. In any case,
> >>> we don't claim to produce a copy of the original software we only
> >>> emulate. In short, Xenomai is a Chameleon, not a clone.
> >>>
> >>>   
> >>>       
> >>>> If any of my assumptions is false or if you have any comment/answers
> >>>> please reply.
> >>>>
> >>>>
> >>>> thanks
> >>>>
> >>>> Ravid
> >>>>
> >>>>     
> >>>>         
> >>     
> 
> 
-- 
Philippe.

Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

Ravid Baruch Naali wrote:
> The automated chart seems exactly the thing for me (I have some testing
> tools development experience).
> 
> I'll look into it and will soon send a initial design.

Hurray! You just deserved an option for a free beer! Now you just need
to post the first related patch - and manage to meet me personally (the
latter may be a bit trickier than the former ;)).

> 
> Of course any pinters/advice/suggestions will be highly appreciated.

Let's start with creating the infrastructure for the targets firsts.
Once we have more tests with unified output locally on the Xenomai
targets, we can think about how to transfer this data to a central
database and how to visualise that database on the web.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]