Re: [Xenomai-core] RTDM and Timer functions
Rodrigo Rosenfeld Rosas wrote: I really tried to not answer this message and finish the endless thread you mentioned, but I couldn't resist. ;) Maybe this will be the last post from my own on this thread and will begin writing in the new thread. See below, please. Don't bother with self-censorship, AFAIC, the issues you are triggering are important ones, since RTDM is a critical piece of the Xenomai framework, and allowing users to leverage it efficiently will help us all. However, please don't top post and trim the old messages a bit more from your replies: unfortunately, my brain has a limited FIFO. TIA, Em Terça 14 Março 2006 17:29, Jan Kiszka escreveu: ... Ok, your framework is effectively aiming for relative times here, that's clear now. But your driver will deliver individual frames with absolute timestamp, right? Right. Then it's up to the user to NOT mix up these timestamps with dates obtained from the system clock. You will have to state this clearly! Sure, of course. No problem with that. Moreover, when considering the TSC as high-resolution timestamp source, this is not applicable on SMP / multicore systems. Those tend to have unsynchronised and drifting TSCs. So if the first picture was taken on one CPU and the second on some other... Unfortunately I can not arguee on that for now since I know almost nothing about SMP systems. I'll take a look on the topic and hopely soon I'll return you what I think about it. I'm not talking especifically about this application, but giving you a general idea of what is not possible to do currently with RTDM if the application set the timer to periodic. And as I have this general view in mind, I want to avoid that the TSC issue gets exported via RTDM drivers to the user. That's already problematic for the other skins, but having to write special notes all over the documentation of dozens of driver using mixed clocks would be very unhandy. I don't understand why adding a new function like this would change a lot the documentation. I really can not see your worries... If you could give me a practical example, maybe it would be easier for me... I see the need for having a high-resolution timestamp aside a low-overhead and low-resolution timer now, good, got an ally. ;) and I think we need to look for a way to avoid its negative sides. First I need to understand better what exactly are the negative sides... Not sure yet if it will be feasible, but I will come up with a new thread on this topic soon... Yes, I've seen. I'll discuss next messages there. Thank you, Rodrigo. ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Anders Blomdell wrote: Jan Kiszka wrote: ... Thinking about this more thoroughly, a few questions popped up for me: o When we call it rtdm_clock_read_tsc(), we should actually return the raw TSC values, shouln't we? But then we also need conversion functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always convert to nanoseconds on return? POSIX and Native are different in this regard. o What would be the core rationale behind it, having a high-resolution time stamp? What are the primary use cases? I'm asking for this so that I can clearly differentiate between this new service and the existing one in the docs. Also, giving an abstract description would leave more options to the actual implementation on other archs or platforms. If you implement it, don't forget to point out that the tsc may have increments varying over time (due to clock scaling), and might even stop for long periods (ACPI sleep), just so we are not faced with a primitive that makes it impossible to implement low-power operation (not at the very top on my priority list, but still important). Yeah, one reason why I'm hesitating ATM to introduce a too specific service to RTDM. But I'm still open to being persuaded about its usefulness. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Terça 14 Março 2006 03:44, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Em Segunda 13 Março 2006 20:05, Jan Kiszka escreveu:
...
We would definitely need a good name for it,
rtdm_clock_read_ex(clock-id), rtdm_clock_read_tsc(),
rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read()
by adding an argument (otherwise, I would have to fix too many drivers
on my own... :-/).
That is the idea, I think. I agree that rtdm_clock_read() should be kept
as it is (the API/definition). No body is asking you to change it.
Adding rtdm_clock_read_tsc() would be sufficient in my opinion whilst it
maintain coherency with other skins.
Thinking about this more thoroughly, a few questions popped up for me:
o When we call it rtdm_clock_read_tsc(), we should actually return the
raw TSC values, shouln't we? But then we also need conversion
functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
convert to nanoseconds on return? POSIX and Native are different in
this regard.
I would prefer returning always ns, but both solutions would fit my needs,
so I'm not really worried about this topic.
o What would be the core rationale behind it, having a high-resolution
time stamp? What are the primary use cases? I'm asking for this so
that I can clearly differentiate between this new service and the
existing one in the docs. Also, giving an abstract description would
leave more options to the actual implementation on other archs or
platforms.
As I've said, I think that it is good to give some independency to the
driver, at least to the time related functions, for not depending on the
user chosen timer behaviour for some delay routines. Eg, I would like to
wait a specified amount of us before testing some register. That is a
quite normal task when
This is what rtdm_task_busy_sleep() already provides - independent of
the system timer.
I didn't know it was independent from the timer. Good to know. I think it
would worth enforce this statement on its documentation.
developing drivers. Another one is for timeouts on short delays. In those
cases, we want a good resolution, but this should be independent of the
user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take a look in my case. The specification recommends wait at least Xus
before testing a bit. But the time to wait is not constant, it can vary a few
microseconds. So, I busy wait Xus and then do some code like:
rtdm_task_busy_sleep(X*1000);
start_time = rtdm_clock_read[_tsc]();
do {
condition=testbit();
} while (! condition (time_passed(start_time) TIMEOUT));
But if the user specifies a periodic timer, with tickval=1ms, then my driver
will be too slow. I could busy wait TIMEOUT before testing, and it would be
faster then the above code in this case. But I would like to go away as soon
as possible, ie, just after the bit has been set...
Again, when the user / system administrator decided to lower the timer
resolution in favour of performance, it is not possible (and doesn't
make sense) to circumvent this decision at driver level (except for busy
waiting).
But my situation is still a busy wait but written in another form.
So, I wonder what you plan to do with the return value of the
new function?
I think I've already explained myself.
Best regards,
Rodrigo.
___
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution, but this should be independent
of the user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take a look in my case. The specification recommends wait at least
Xus before testing a bit. But the time to wait is not constant, it can
vary a few microseconds. So, I busy wait Xus and then do some code like:
rtdm_task_busy_sleep(X*1000);
start_time = rtdm_clock_read[_tsc]();
do {
condition=testbit();
} while (! condition (time_passed(start_time) TIMEOUT));
But if the user specifies a periodic timer, with tickval=1ms, then my
driver will be too slow. I could busy wait TIMEOUT before testing, and it
would be faster then the above code in this case. But I would like to go
away as soon as possible, ie, just after the bit has been set...
This is how the eepr100 driver of RTnet handles it, though RTnet would
not work very well in periodic mode. Actually, this has been ported over
from Linux where you do not have a portable API for reading the TSC, I
think.
static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
{
int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
while (inb(cmd_ioaddr) != 0) {
if (wait-- == 0)
return 1;
rtdm_task_busy_sleep(1000);
}
return 0;
}
(Hmm, BTW, de-inlining might be worth considering...)
So this works at a polling period of 1 us, but you may also reduce it,
though this would certainly degrade the accuracy further. For sure, the
accuracy is slightly worse than with your pattern. Would this matter to you?
No, in my case it doesn't matter. I'll adopt this way of doing it.
Thank you,
Rodrigo.
___
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Rodrigo Rosenfeld Rosas wrote:
Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution, but this should be independent
of the user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take a look in my case. The specification recommends wait at
least Xus before testing a bit. But the time to wait is not constant, it
can vary a few microseconds. So, I busy wait Xus and then do some code
like:
rtdm_task_busy_sleep(X*1000);
start_time = rtdm_clock_read[_tsc]();
do {
condition=testbit();
} while (! condition (time_passed(start_time) TIMEOUT));
But if the user specifies a periodic timer, with tickval=1ms, then my
driver will be too slow. I could busy wait TIMEOUT before testing, and it
would be faster then the above code in this case. But I would like to go
away as soon as possible, ie, just after the bit has been set...
This is how the eepr100 driver of RTnet handles it, though RTnet would
not work very well in periodic mode. Actually, this has been ported over
from Linux where you do not have a portable API for reading the TSC, I
think.
static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
{
int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
while (inb(cmd_ioaddr) != 0) {
if (wait-- == 0)
return 1;
rtdm_task_busy_sleep(1000);
}
return 0;
}
(Hmm, BTW, de-inlining might be worth considering...)
So this works at a polling period of 1 us, but you may also reduce it,
though this would certainly degrade the accuracy further. For sure, the
accuracy is slightly worse than with your pattern. Would this matter to
you?
No, in my case it doesn't matter. I'll adopt this way of doing it.
Thinking better, I would need such a function for registering the timestamp
of
the captured frame on the irq handler...
What will this timestamp be used for, relative time calculations? I just
would like to remind that the output of rtdm_clock_read_tsc() will not
be in sync with the system clock in periodic mode (one of my major
concern: that driver writers forget this fact).
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution, but this should be independent
of the user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take a look in my case. The specification recommends wait at
least Xus before testing a bit. But the time to wait is not constant, it
can vary a few microseconds. So, I busy wait Xus and then do some code
like:
rtdm_task_busy_sleep(X*1000);
start_time = rtdm_clock_read[_tsc]();
do {
condition=testbit();
} while (! condition (time_passed(start_time) TIMEOUT));
But if the user specifies a periodic timer, with tickval=1ms, then my
driver will be too slow. I could busy wait TIMEOUT before testing, and it
would be faster then the above code in this case. But I would like to go
away as soon as possible, ie, just after the bit has been set...
This is how the eepr100 driver of RTnet handles it, though RTnet would
not work very well in periodic mode. Actually, this has been ported over
from Linux where you do not have a portable API for reading the TSC, I
think.
static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
{
int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
while (inb(cmd_ioaddr) != 0) {
if (wait-- == 0)
return 1;
rtdm_task_busy_sleep(1000);
}
return 0;
}
(Hmm, BTW, de-inlining might be worth considering...)
So this works at a polling period of 1 us, but you may also reduce it,
though this would certainly degrade the accuracy further. For sure, the
accuracy is slightly worse than with your pattern. Would this matter to
you?
No, in my case it doesn't matter. I'll adopt this way of doing it.
Thinking better, I would need such a function for registering the timestamp of
the captured frame on the irq handler...
Rodrigo.
___
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Terça 14 Março 2006 16:00, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution, but this should be
independent of the user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take a look in my case. The specification recommends wait at
least Xus before testing a bit. But the time to wait is not constant,
it can vary a few microseconds. So, I busy wait Xus and then do some
code like:
rtdm_task_busy_sleep(X*1000);
start_time = rtdm_clock_read[_tsc]();
do {
condition=testbit();
} while (! condition (time_passed(start_time) TIMEOUT));
But if the user specifies a periodic timer, with tickval=1ms, then my
driver will be too slow. I could busy wait TIMEOUT before testing, and
it would be faster then the above code in this case. But I would like
to go away as soon as possible, ie, just after the bit has been set...
This is how the eepr100 driver of RTnet handles it, though RTnet would
not work very well in periodic mode. Actually, this has been ported over
from Linux where you do not have a portable API for reading the TSC, I
think.
static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
{
int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
while (inb(cmd_ioaddr) != 0) {
if (wait-- == 0)
return 1;
rtdm_task_busy_sleep(1000);
}
return 0;
}
(Hmm, BTW, de-inlining might be worth considering...)
So this works at a polling period of 1 us, but you may also reduce it,
though this would certainly degrade the accuracy further. For sure, the
accuracy is slightly worse than with your pattern. Would this matter to
you?
No, in my case it doesn't matter. I'll adopt this way of doing it.
Thinking better, I would need such a function for registering the
timestamp of the captured frame on the irq handler...
What will this timestamp be used for, relative time calculations? I just
would like to remind that the output of rtdm_clock_read_tsc() will not
be in sync with the system clock in periodic mode (one of my major
concern: that driver writers forget this fact).
But that is exactly what I need. Suppose that a robot control system uses two
images to estimate the robot speed. The application may need a control loop
of, say, 100ms, putting the periodic timer set to 1, 10 or 100ms. But,
suppose that in each loop it takes two images in a short time interval (less
then 100ms or even less then 1ms) and the real time interval is very
important. So the driver must pass the timestamp of each captured frame to
application loop. But those times shouldn't be multiple of the timer tick,
but the real time with all precision it can get.
I'm not talking especifically about this application, but giving you a general
idea of what is not possible to do currently with RTDM if the application set
the timer to periodic.
Regards,
Rodrigo.
___
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Rodrigo Rosenfeld Rosas wrote:
Em Terça 14 Março 2006 16:00, Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
... Another one is for timeouts on short delays. In
those cases, we want a good resolution, but this should be
independent of the user's timer choice IMO.
And this is something rtdm_clock_read_tsc() will obviously not be for.
Please, take a look in my case. The specification recommends wait at
least Xus before testing a bit. But the time to wait is not constant,
it can vary a few microseconds. So, I busy wait Xus and then do some
code like:
rtdm_task_busy_sleep(X*1000);
start_time = rtdm_clock_read[_tsc]();
do {
condition=testbit();
} while (! condition (time_passed(start_time) TIMEOUT));
But if the user specifies a periodic timer, with tickval=1ms, then my
driver will be too slow. I could busy wait TIMEOUT before testing, and
it would be faster then the above code in this case. But I would like
to go away as soon as possible, ie, just after the bit has been set...
This is how the eepr100 driver of RTnet handles it, though RTnet would
not work very well in periodic mode. Actually, this has been ported over
from Linux where you do not have a portable API for reading the TSC, I
think.
static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
{
int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
while (inb(cmd_ioaddr) != 0) {
if (wait-- == 0)
return 1;
rtdm_task_busy_sleep(1000);
}
return 0;
}
(Hmm, BTW, de-inlining might be worth considering...)
So this works at a polling period of 1 us, but you may also reduce it,
though this would certainly degrade the accuracy further. For sure, the
accuracy is slightly worse than with your pattern. Would this matter to
you?
No, in my case it doesn't matter. I'll adopt this way of doing it.
Thinking better, I would need such a function for registering the
timestamp of the captured frame on the irq handler...
What will this timestamp be used for, relative time calculations? I just
would like to remind that the output of rtdm_clock_read_tsc() will not
be in sync with the system clock in periodic mode (one of my major
concern: that driver writers forget this fact).
But that is exactly what I need. Suppose that a robot control system uses two
images to estimate the robot speed. The application may need a control loop
of, say, 100ms, putting the periodic timer set to 1, 10 or 100ms. But,
suppose that in each loop it takes two images in a short time interval (less
then 100ms or even less then 1ms) and the real time interval is very
important. So the driver must pass the timestamp of each captured frame to
application loop. But those times shouldn't be multiple of the timer tick,
but the real time with all precision it can get.
Ok, your framework is effectively aiming for relative times here, that's
clear now. But your driver will deliver individual frames with absolute
timestamp, right? Then it's up to the user to NOT mix up these
timestamps with dates obtained from the system clock. You will have to
state this clearly!
Moreover, when considering the TSC as high-resolution timestamp source,
this is not applicable on SMP / multicore systems. Those tend to have
unsynchronised and drifting TSCs. So if the first picture was taken on
one CPU and the second on some other...
I'm not talking especifically about this application, but giving you a
general
idea of what is not possible to do currently with RTDM if the application set
the timer to periodic.
And as I have this general view in mind, I want to avoid that the TSC
issue gets exported via RTDM drivers to the user. That's already
problematic for the other skins, but having to write special notes all
over the documentation of dozens of driver using mixed clocks would be
very unhandy.
I see the need for having a high-resolution timestamp aside a
low-overhead and low-resolution timer now, and I think we need to look
for a way to avoid its negative sides. Not sure yet if it will be
feasible, but I will come up with a new thread on this topic soon...
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
I really tried to not answer this message and finish the endless thread you mentioned, but I couldn't resist. ;) Maybe this will be the last post from my own on this thread and will begin writing in the new thread. See below, please. Em Terça 14 Março 2006 17:29, Jan Kiszka escreveu: ... Ok, your framework is effectively aiming for relative times here, that's clear now. But your driver will deliver individual frames with absolute timestamp, right? Right. Then it's up to the user to NOT mix up these timestamps with dates obtained from the system clock. You will have to state this clearly! Sure, of course. No problem with that. Moreover, when considering the TSC as high-resolution timestamp source, this is not applicable on SMP / multicore systems. Those tend to have unsynchronised and drifting TSCs. So if the first picture was taken on one CPU and the second on some other... Unfortunately I can not arguee on that for now since I know almost nothing about SMP systems. I'll take a look on the topic and hopely soon I'll return you what I think about it. I'm not talking especifically about this application, but giving you a general idea of what is not possible to do currently with RTDM if the application set the timer to periodic. And as I have this general view in mind, I want to avoid that the TSC issue gets exported via RTDM drivers to the user. That's already problematic for the other skins, but having to write special notes all over the documentation of dozens of driver using mixed clocks would be very unhandy. I don't understand why adding a new function like this would change a lot the documentation. I really can not see your worries... If you could give me a practical example, maybe it would be easier for me... I see the need for having a high-resolution timestamp aside a low-overhead and low-resolution timer now, good, got an ally. ;) and I think we need to look for a way to avoid its negative sides. First I need to understand better what exactly are the negative sides... Not sure yet if it will be feasible, but I will come up with a new thread on this topic soon... Yes, I've seen. I'll discuss next messages there. Thank you, Rodrigo. ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Rodrigo Rosenfeld Rosas wrote: I really tried to not answer this message and finish the endless thread you mentioned, but I couldn't resist. ;) Maybe this will be the last post from my own on this thread and will begin writing in the new thread. See below, please. I see no problem in continuing it. I guess most subscribers already created special deletion filter for its keywords anyway. ;) Em Terça 14 Março 2006 17:29, Jan Kiszka escreveu: ... Ok, your framework is effectively aiming for relative times here, that's clear now. But your driver will deliver individual frames with absolute timestamp, right? Right. Then it's up to the user to NOT mix up these timestamps with dates obtained from the system clock. You will have to state this clearly! Sure, of course. No problem with that. Moreover, when considering the TSC as high-resolution timestamp source, this is not applicable on SMP / multicore systems. Those tend to have unsynchronised and drifting TSCs. So if the first picture was taken on one CPU and the second on some other... Unfortunately I can not arguee on that for now since I know almost nothing about SMP systems. I'll take a look on the topic and hopely soon I'll return you what I think about it. Then let me continue my sentence: ... the timestamps can not be used to calculate the delay between both of them. The reason is that you are lacking the offset between both TSC sources at the respective timestamp acquisition dates. I'm not talking especifically about this application, but giving you a general idea of what is not possible to do currently with RTDM if the application set the timer to periodic. And as I have this general view in mind, I want to avoid that the TSC issue gets exported via RTDM drivers to the user. That's already problematic for the other skins, but having to write special notes all over the documentation of dozens of driver using mixed clocks would be very unhandy. I don't understand why adding a new function like this would change a lot the documentation. I really can not see your worries... If you could give me a practical example, maybe it would be easier for me... A driver that reports TSC timestamps instead of system clock timestamps to the user has to state this fact and its potential effects in periodic mode - as long as both clocks are out of sync. My idea is now to synchronise them and report corrected TSC-based timestamps via rtdm_clock_read() when in periodic mode. No need for new functions, use the old one, and all your problems would be solved automatically. I see the need for having a high-resolution timestamp aside a low-overhead and low-resolution timer now, good, got an ally. ;) and I think we need to look for a way to avoid its negative sides. First I need to understand better what exactly are the negative sides... Not sure yet if it will be feasible, but I will come up with a new thread on this topic soon... Yes, I've seen. I'll discuss next messages there. Thank you, Rodrigo. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Rodrigo Rosenfeld Rosas wrote: Actually, I noted a minor typo error in the documentation: of the this service should be of this service this is the kind of thing that youre encouraged to create a patch for. Same for other doc nits - youre offering 'something-like' suggestions, when you could almost as easily prep an actual patch with your best wording. Also please start trimming much more agressively. None of us need to see 3 or 4 xenomai footers, and more yahoo ones besides. thanks ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Segunda 13 Março 2006 08:48, você escreveu: ... Do you mean that rtdm_clock_read will always read a multiple of tickval value? If so, I think it would be good to make it clear on its documentation. Get system time isn't enough for getting this information, IMHO. Please have a look at the two sentences of documentation I added to SVN (didn't make it into the release). I did. I gave your scenario a try, and I was able to verify that rtdm_task_busy_sleep works correctly under both timer modes. I cannot understand yet why it doesn't occur here, but I'll investigate if I have the time to. Indeed, the behaviour of rtdm_clock_read may have been confusing due to lacking information, but it was also correct. I liked the note, but I would include another one: When in periodic mode, the time resolution is limited to the tick set to the system timer or something like. Maybe: [If using periodic mode, note that ]The time resolution is limited by the system timer tick. Well my English is not that good, so I think you could give a better description, but I really need this note is very useful. Using something different (e.g. always TSC) would break applications specifying absolute times derived from the return values of other skins' functions. I did not understand. I'm talking about using TSC only for these two functions. I can not see why shouldn't it be possible... I mean, I think the driver should not depend on the userspace program timer for these two functions. But the worst case is that sometimes I get Should be near 84000: 0 which clearly is a incorrect result. That might be a rounding issue somewhere, as the sleep than clearly did not wait at least one tick. Will have to check this when time permits. After I run the latency program, the timer turns to be oneshot again and everything goes right. What can I do to solve this problem? Use oneshot mode in the meantime - or even longer ;). That is what I'll gonna do, but I know it is not a definite solution. Since I'm providing a framework, the user should decide which approach is better for him/her, oneshot or periodic mode. Why do you prefer periodic mode for your application? Another workaround: reduce the tick interval. I have some loops in my userspace programs that a common 100us tick would satisfy them all. I think the overhead would be lower than using the aperiodic oneshot mode... I'm not pretty sure about that. But that is not the question. My application is just an use case of my framework (actually I didn't even started building it). The final user should decide what is the best approach for him/her, not me. So, I would prefer that the driver be independent from the timer source chosen by the user program. I see your point. But when the user decides to pick a low-precision timer source to reduce overhead, (s)he has to live with the side-effect. There is no such thing like user vs. kernel timer source - it is always the same. Thus, also the precision of time stamping in drivers suffers. Ok, I'll document this on my framework. Thanks for the support, Rodrigo. ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Jan Kiszka wrote: Sometimes the result is Should be near 84000: 10, that is kind of correct, since the tickval is 10, although I think that those functions in the RTDM driver context should be independent of the tick value set by the user program... Maybe using oneshot in the driver calls and periodic in the application... I really don't know what would be the best approach here... rtdm_clock_read always uses the nucleus clock. Using something different (e.g. always TSC) would break applications specifying absolute times derived from the return values of other skins' functions. Maybe adding a service to RTDM would allow users to measure short time intervals with RTDM using the TSC ? The native (rt_timer_tsc()) and posix (clock_gettime(CLOCK_MONOTONIC)) skins have a way to do this. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Sorry Jan, I was looking at a different documentation. Now I read the right one. It is good. But I didn't understand why didn't you keep the latter note: The nucleus timer has to be started to obtain valid results. I would include it before the other note. Thank you, Rodrigo. Em Segunda 13 Março 2006 14:15, Rodrigo Rosenfeld Rosas escreveu: Em Segunda 13 Março 2006 11:54, Rodrigo Rosenfeld Rosas escreveu: I liked the note, but I would include another one: When in periodic mode, the time resolution is limited to the tick set to the system timer or something like. Maybe: [If using periodic mode, note that ]The time resolution is limited by the system timer tick. Well my English is not that good, so I think you could give a better description, but I really need this note is very useful. Actually, I would add them to rtdm_task_busy_sleep() documentation too. Rodrigo. ___ Yahoo! Acesso Grtis - Internet rpida e grtis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Rodrigo Rosenfeld Rosas wrote: Sorry Jan, I was looking at a different documentation. Now I read the right one. It is good. But I didn't understand why didn't you keep the latter note: The nucleus timer has to be started to obtain valid results. I would include it before the other note. Well, it's no longer relevant for Xenomai: you can't load a driver without the timer being started - loading xeno_rtdm will do this. On the other hand, you are right when considering RTAI where you still face this obstacle. I will re-introduce the note below, but the strategy will remain that it's up to the user (application) to resolve this. The system timer has to be started to obtain valid results. If this happens automatically or is controlled by the application depends on the RTDM host environment, see related documentation of the real-time Linux extension. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Rodrigo Rosenfeld Rosas wrote: Em Segunda 13 Março 2006 08:48, você escreveu: ... Do you mean that rtdm_clock_read will always read a multiple of tickval value? If so, I think it would be good to make it clear on its documentation. Get system time isn't enough for getting this information, IMHO. Please have a look at the two sentences of documentation I added to SVN (didn't make it into the release). I did. I gave your scenario a try, and I was able to verify that rtdm_task_busy_sleep works correctly under both timer modes. I cannot understand yet why it doesn't occur here, but I'll investigate if I have the time to. I counted the loops rtdm_task_busy_sleep took, and they were quite similar (IRQ noise aside). Indeed, the behaviour of rtdm_clock_read may have been confusing due to lacking information, but it was also correct. I liked the note, but I would include another one: When in periodic mode, the time resolution is limited to the tick set to the system timer or something like. Maybe: [If using periodic mode, note that ]The time resolution is limited by the system timer tick. Well my English is not that good, so I think you could give a better description, but I really need this note is very useful. Resolution is the accurate term, indeed. To include what I think is the core of your suggestions: The resolution of the this service depends on the system timer. In particular, if the system timer is running in periodic mode, the return value will be limited to multiples of the timer tick period. Actually, the resolution based on TSC is also limited - when your CPU has less then 1 GHz. ;) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Actually, I noted a minor typo error in the documentation: of the this service should be of this service Best Regards, Rodrigo. Em Segunda 13 Março 2006 14:58, Rodrigo Rosenfeld Rosas escreveu: Sorry Jan, I was looking at a different documentation. Now I read the right one. It is good. But I didn't understand why didn't you keep the latter note: The nucleus timer has to be started to obtain valid results. I would include it before the other note. Thank you, Rodrigo. Em Segunda 13 Março 2006 14:15, Rodrigo Rosenfeld Rosas escreveu: Em Segunda 13 Março 2006 11:54, Rodrigo Rosenfeld Rosas escreveu: I liked the note, but I would include another one: When in periodic mode, the time resolution is limited to the tick set to the system timer or something like. Maybe: [If using periodic mode, note that ]The time resolution is limited by the system timer tick. Well my English is not that good, so I think you could give a better description, but I really need this note is very useful. Actually, I would add them to rtdm_task_busy_sleep() documentation too. Rodrigo. ___ Yahoo! Acesso Grtis - Internet rpida e grtis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Yahoo! Acesso Grtis - Internet rpida e grtis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Segunda 13 Março 2006 15:24, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Sorry Jan, I was looking at a different documentation. Now I read the right one. It is good. But I didn't understand why didn't you keep the latter note: The nucleus timer has to be started to obtain valid results. I would include it before the other note. Well, it's no longer relevant for Xenomai: you can't load a driver without the timer being started - loading xeno_rtdm will do this. On the other hand, you are right when considering RTAI where you still face this obstacle. I will re-introduce the note below, but the strategy will remain that it's up to the user (application) to resolve this. The system timer has to be started to obtain valid results. If this happens automatically or is controlled by the application depends on the RTDM host environment, see related documentation of the real-time Linux extension. I would add a little, but significant comment with: The system timer has to be started to obtain valid results. If this happens automatically (as it does on Xenomai) or is controlled by the application depends on the RTDM host environment, see related documentation of the real-time Linux extension. Regards, Rodrigo. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Segunda 13 Março 2006 15:33, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Em Segunda 13 Março 2006 14:25, Gilles Chanteperdrix escreveu: Jan Kiszka wrote: Sometimes the result is Should be near 84000: 10, that is kind of correct, since the tickval is 10, although I think that those functions in the RTDM driver context should be independent of the tick value set by the user program... Maybe using oneshot in the driver calls and periodic in the application... I really don't know what would be the best approach here... rtdm_clock_read always uses the nucleus clock. Using something different (e.g. always TSC) would break applications specifying absolute times derived from the return values of other skins' functions. Maybe adding a service to RTDM would allow users to measure short time intervals with RTDM using the TSC ? The native (rt_timer_tsc()) and posix (clock_gettime(CLOCK_MONOTONIC)) skins have a way to do this. This would fit great for my needs (and most developers I think)! Will think about it. Actually, I'm not a big fan of this. It creates the risk that someone feeds the output of this service into (incompatible) timed RTDM services. Sorry, I couldn't see a practical usage of this. Could you give an example? Even worse, this would work for aperiodic mode but fail for periodic. Actually it is only necessary on periodic modes as it already works for aperiodic mode. We would definitely need a good name for it, rtdm_clock_read_ex(clock-id), rtdm_clock_read_tsc(), rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by adding an argument (otherwise, I would have to fix too many drivers on my own... :-/). That is the idea, I think. I agree that rtdm_clock_read() should be kept as it is (the API/definition). No body is asking you to change it. Adding rtdm_clock_read_tsc() would be sufficient in my opinion whilst it maintain coherency with other skins. Thank you for considering it. Rodrigo. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Segunda 13 Março 2006 20:05, Jan Kiszka escreveu: ... We would definitely need a good name for it, rtdm_clock_read_ex(clock-id), rtdm_clock_read_tsc(), rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by adding an argument (otherwise, I would have to fix too many drivers on my own... :-/). That is the idea, I think. I agree that rtdm_clock_read() should be kept as it is (the API/definition). No body is asking you to change it. Adding rtdm_clock_read_tsc() would be sufficient in my opinion whilst it maintain coherency with other skins. Thinking about this more thoroughly, a few questions popped up for me: o When we call it rtdm_clock_read_tsc(), we should actually return the raw TSC values, shouln't we? But then we also need conversion functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always convert to nanoseconds on return? POSIX and Native are different in this regard. I would prefer returning always ns, but both solutions would fit my needs, so I'm not really worried about this topic. o What would be the core rationale behind it, having a high-resolution time stamp? What are the primary use cases? I'm asking for this so that I can clearly differentiate between this new service and the existing one in the docs. Also, giving an abstract description would leave more options to the actual implementation on other archs or platforms. As I've said, I think that it is good to give some independency to the driver, at least to the time related functions, for not depending on the user chosen timer behaviour for some delay routines. Eg, I would like to wait a specified amount of us before testing some register. That is a quite normal task when developing drivers. Another one is for timeouts on short delays. In those cases, we want a good resolution, but this should be independent of the user's timer choice IMO. Rodrigo. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Quinta 09 Março 2006 17:33, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Hi Jan, I'm still concerned about the future of RTDM and timer functions. I think there should be some function for starting the timer manually, since the automatic feature don't work great for RTDM drivers. It is not nice to have to run the latency (or any other) program for starting the timer before I can load my driver. And it is not suffice to run it once I booted. After I open/close my rtdm device and reload my driver the problem will occur again and I'll have to re-run the latency program. Sorry I don't see the problem here. # modprobe xeno_nucleus; cat /proc/xenomai/timer status=off:setup=1392:tickval=0:jiffies=0 # modprobe xeno_rtdm; cat /proc/xenomai/timer status=oneshot:setup=1392:tickval=1:jiffies=8113917792696 So the timer is running right since when rtdm is loaded?! Yes, here too. And that simple heartbeat rtdm example on my rt-addon homepage now cleanly runs even without any further helper to start some timer. Yes, here too. You are right, once the timer is in oneshot mode. My driver loads correctly without the helper. Then I start a user application that changes the timer to periodic mode and uses my driver. When I reload my driver, now in periodic mode, the problem raises. It seems, there is no problem when the timer is set to oneshot. But when turning it to periodic, at least one of rtdm_task_busy_sleep() or rtdm_clock_read() doesn't seem to work. See below: cat /proc/xenomai/timer status=periodic:setup=188:tickval=10:jiffies=19972453 start_time = rtdm_clock_read(); rtdm_task_busy_sleep(84000); temp_time = rtdm_clock_read(); rtdm_printk(KERN_INFO Should be near 84000: %u\n, (unsigned int) (temp_time-start_time)); Sometimes the result is Should be near 84000: 10, that is kind of correct, since the tickval is 10, although I think that those functions in the RTDM driver context should be independent of the tick value set by the user program... Maybe using oneshot in the driver calls and periodic in the application... I really don't know what would be the best approach here... But the worst case is that sometimes I get Should be near 84000: 0 which clearly is a incorrect result. After I run the latency program, the timer turns to be oneshot again and everything goes right. What can I do to solve this problem? Thanks in advance, Rodrigo. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Rodrigo Rosenfeld Rosas wrote: Em Quinta 09 Março 2006 17:33, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Hi Jan, I'm still concerned about the future of RTDM and timer functions. I think there should be some function for starting the timer manually, since the automatic feature don't work great for RTDM drivers. It is not nice to have to run the latency (or any other) program for starting the timer before I can load my driver. And it is not suffice to run it once I booted. After I open/close my rtdm device and reload my driver the problem will occur again and I'll have to re-run the latency program. Sorry I don't see the problem here. # modprobe xeno_nucleus; cat /proc/xenomai/timer status=off:setup=1392:tickval=0:jiffies=0 # modprobe xeno_rtdm; cat /proc/xenomai/timer status=oneshot:setup=1392:tickval=1:jiffies=8113917792696 So the timer is running right since when rtdm is loaded?! Yes, here too. And that simple heartbeat rtdm example on my rt-addon homepage now cleanly runs even without any further helper to start some timer. Yes, here too. You are right, once the timer is in oneshot mode. My driver loads correctly without the helper. Then I start a user application that changes the timer to periodic mode and uses my driver. When I reload my driver, now in periodic mode, the problem raises. What happens if you make the periodic timer the default one in the kernel configuration? It seems, there is no problem when the timer is set to oneshot. But when turning it to periodic, at least one of rtdm_task_busy_sleep() or rtdm_clock_read() doesn't seem to work. See below: cat /proc/xenomai/timer status=periodic:setup=188:tickval=10:jiffies=19972453 start_time = rtdm_clock_read(); rtdm_task_busy_sleep(84000); temp_time = rtdm_clock_read(); rtdm_printk(KERN_INFO Should be near 84000: %u\n, (unsigned int) (temp_time-start_time)); Sometimes the result is Should be near 84000: 10, that is kind of correct, since the tickval is 10, although I think that those functions in the RTDM driver context should be independent of the tick value set by the user program... Maybe using oneshot in the driver calls and periodic in the application... I really don't know what would be the best approach here... rtdm_clock_read always uses the nucleus clock. Using something different (e.g. always TSC) would break applications specifying absolute times derived from the return values of other skins' functions. But the worst case is that sometimes I get Should be near 84000: 0 which clearly is a incorrect result. That might be a rounding issue somewhere, as the sleep than clearly did not wait at least one tick. Will have to check this when time permits. After I run the latency program, the timer turns to be oneshot again and everything goes right. What can I do to solve this problem? Use oneshot mode in the meantime - or even longer ;). Why do you prefer periodic mode for your application? Another workaround: reduce the tick interval. Thanks in advance, Rodrigo. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Em Sexta 10 Março 2006 15:32, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Em Quinta 09 Março 2006 17:33, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Hi Jan, I'm still concerned about the future of RTDM and timer functions. I think there should be some function for starting the timer manually, since the automatic feature don't work great for RTDM drivers. It is not nice to have to run the latency (or any other) program for starting the timer before I can load my driver. And it is not suffice to run it once I booted. After I open/close my rtdm device and reload my driver the problem will occur again and I'll have to re-run the latency program. Sorry I don't see the problem here. # modprobe xeno_nucleus; cat /proc/xenomai/timer status=off:setup=1392:tickval=0:jiffies=0 # modprobe xeno_rtdm; cat /proc/xenomai/timer status=oneshot:setup=1392:tickval=1:jiffies=8113917792696 So the timer is running right since when rtdm is loaded?! Yes, here too. And that simple heartbeat rtdm example on my rt-addon homepage now cleanly runs even without any further helper to start some timer. Yes, here too. You are right, once the timer is in oneshot mode. My driver loads correctly without the helper. Then I start a user application that changes the timer to periodic mode and uses my driver. When I reload my driver, now in periodic mode, the problem raises. What happens if you make the periodic timer the default one in the kernel configuration? The same behaviour. It seems, there is no problem when the timer is set to oneshot. But when turning it to periodic, at least one of rtdm_task_busy_sleep() or rtdm_clock_read() doesn't seem to work. See below: cat /proc/xenomai/timer status=periodic:setup=188:tickval=10:jiffies=19972453 start_time = rtdm_clock_read(); rtdm_task_busy_sleep(84000); temp_time = rtdm_clock_read(); rtdm_printk(KERN_INFO Should be near 84000: %u\n, (unsigned int) (temp_time-start_time)); Sometimes the result is Should be near 84000: 10, that is kind of correct, since the tickval is 10, although I think that those functions in the RTDM driver context should be independent of the tick value set by the user program... Maybe using oneshot in the driver calls and periodic in the application... I really don't know what would be the best approach here... rtdm_clock_read always uses the nucleus clock. Do you mean that rtdm_clock_read will always read a multiple of tickval value? If so, I think it would be good to make it clear on its documentation. Get system time isn't enough for getting this information, IMHO. Using something different (e.g. always TSC) would break applications specifying absolute times derived from the return values of other skins' functions. I did not understand. I'm talking about using TSC only for these two functions. I can not see why shouldn't it be possible... I mean, I think the driver should not depend on the userspace program timer for these two functions. But the worst case is that sometimes I get Should be near 84000: 0 which clearly is a incorrect result. That might be a rounding issue somewhere, as the sleep than clearly did not wait at least one tick. Will have to check this when time permits. After I run the latency program, the timer turns to be oneshot again and everything goes right. What can I do to solve this problem? Use oneshot mode in the meantime - or even longer ;). That is what I'll gonna do, but I know it is not a definite solution. Since I'm providing a framework, the user should decide which approach is better for him/her, oneshot or periodic mode. Why do you prefer periodic mode for your application? Another workaround: reduce the tick interval. I have some loops in my userspace programs that a common 100us tick would satisfy them all. I think the overhead would be lower than using the aperiodic oneshot mode... I'm not pretty sure about that. But that is not the question. My application is just an use case of my framework (actually I didn't even started building it). The final user should decide what is the best approach for him/her, not me. So, I would prefer that the driver be independent from the timer source chosen by the user program. Rodrigo. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM and Timer functions
Rodrigo Rosenfeld Rosas wrote: Hi Jan, I'm still concerned about the future of RTDM and timer functions. I think there should be some function for starting the timer manually, since the automatic feature don't work great for RTDM drivers. It is not nice to have to run the latency (or any other) program for starting the timer before I can load my driver. And it is not suffice to run it once I booted. After I open/close my rtdm device and reload my driver the problem will occur again and I'll have to re-run the latency program. Sorry I don't see the problem here. # modprobe xeno_nucleus; cat /proc/xenomai/timer status=off:setup=1392:tickval=0:jiffies=0 # modprobe xeno_rtdm; cat /proc/xenomai/timer status=oneshot:setup=1392:tickval=1:jiffies=8113917792696 So the timer is running right since when rtdm is loaded?! And that simple heartbeat rtdm example on my rt-addon homepage now cleanly runs even without any further helper to start some timer. Do you have any plans to correct this undesirable behaviour? I don't even have an idea why the timer stops once it is started... Actually I'm not sure why does rtdm_clock_read should depend on the xenomai timer. At least, I think there should be a note in the rtdm_clock_read documentation stating that it only works after the timer has been started. Best Regards, Rodrigo. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
