On 10/11/2005 05:11 PM Fillod Stephane wrote:
> Heikki Lindholm wrote:
> [..]
>> Probably, but there are less than awesome 4xx boards around and I'd
>> guess they might even be more likely targets than G4 based machines,
> for
>> example. Some tuning might be needed.
>
> How many people are usin
Fillod Stephane kirjoitti:
Heikki Lindholm wrote:
[..]
Probably, but there are less than awesome 4xx boards around and I'd
guess they might even be more likely targets than G4 based machines,
for
example. Some tuning might be needed.
How many people are using Xenomai (or Fusion) on 4xx
Heikki Lindholm wrote:
[..]
> Probably, but there are less than awesome 4xx boards around and I'd
> guess they might even be more likely targets than G4 based machines,
for
> example. Some tuning might be needed.
How many people are using Xenomai (or Fusion) on 4xx ?
What are their typical sched
Fillod Stephane kirjoitti:
Heikki Lindholm wrote:
The old calibration value was from some ancient ppc32 embedded board,
I
guess. This reflects the awesome power of them ppc64 boxen better :)
Actually, the ppc32 calibration value was from some ancient x86 machine,
Damn, that has been h
Steven Seeger wrote:
> Do you have to ask? :)
>
> rt_timer_start(125000);
Still hoping the code is fine and continuing with stupid questions : did
you check rt_timer_start return value ?
--
Gilles Chanteperdrix.
Heikki Lindholm wrote:
> The old calibration value was from some ancient ppc32 embedded board,
I
> guess. This reflects the awesome power of them ppc64 boxen better :)
Actually, the ppc32 calibration value was from some ancient x86 machine,
I
guess. The same patch could be applied to asm-ppc/cal
The old calibration value was from some ancient ppc32 embedded board, I
guess. This reflects the awesome power of them ppc64 boxen better :)
-- Heikki Lindholm
diff -Nru xenomai/include/nucleus/asm-ppc64/calibration.h
xenomai-dev/include/nucleus/asm-ppc64/calibration.h
--- xenomai/include/nucle
Do you have to ask? :)
rt_timer_start(125000);
On 10/11/05 7:24 AM, "Gilles Chanteperdrix"
<[EMAIL PROTECTED]> wrote:
> Steven Seeger wrote:
>> In periodic mode, rt_timer_ticks2ns should convert ticks to periodic
>> jiffies. However, it always seems to return 0.
>
> Did you call rt_timer_start
Steven Seeger wrote:
> In periodic mode, rt_timer_ticks2ns should convert ticks to periodic
> jiffies. However, it always seems to return 0.
Did you call rt_timer_start before rt_timer_tick2ns ?
--
Gilles Chanteperdrix.
Steven Seeger wrote:
Why is there a different version of this function for user and kernel space?
Because Xeno cannot fire alarm handlers asynchronously in user-space when the
alarm elapses at kernel level. We currently need an alarm server in user-space
to process alarm events synchronously
In periodic mode, rt_timer_ticks2ns should convert ticks to periodic
jiffies. However, it always seems to return 0.
Why is there a different version of this function for user and kernel space?
I don't see this reflected in the docs.
Steven
Heikki Lindholm wrote:
Gilles Chanteperdrix kirjoitti:
> > Having the generated documentation in svn repository also allows
us to
> > copy it to the documentation directory of the download zone from a
> > script run by cron.
> > Ok, this makes sense. But could be done by other means, too,
Gilles Chanteperdrix kirjoitti:
> > Having the generated documentation in svn repository also allows us to
> > copy it to the documentation directory of the download zone from a
> > script run by cron.
>
> Ok, this makes sense. But could be done by other means, too, I guess.
Automatically
Philippe Gerum wrote:
Dmitry Adamushko wrote:
On 11/10/05, Philippe Gerum <[EMAIL PROTECTED]> wrote:
...
So,
1) don't display such names in /proc;
2) make a common mechanism for both spaces.
rt_mutex_create() // for other objects as well
{
...
- xnobject_copy_name(mutex->name,name);
+xnob
Dmitry Adamushko wrote:
On 11/10/05, Philippe Gerum <[EMAIL PROTECTED]> wrote:
...
So,
1) don't display such names in /proc;
2) make a common mechanism for both spaces.
rt_mutex_create() // for other objects as well
{
...
- xnobject_copy_name(mutex->name,name);
+xnobject_create_name(mutex->
On 11/10/05, Philippe Gerum <[EMAIL PROTECTED]> wrote:
> > ...
> > So,
> >
> > 1) don't display such names in /proc;
> > 2) make a common mechanism for both spaces.
> >
> > rt_mutex_create() // for other objects as well
> > {
> > ...
> > - xnobject_copy_name(mutex->name,name);
> > +xnobject_creat
Jim Cromie wrote:
attached patch gives xeno-config a --verbose option, ie:
Well, not really a software bug fix, but might be considered as a simple brain
bug fix for users, so the patch made it even through the feature freeze.
Applied, thanks.
--
Philippe.
Heikki Lindholm wrote:
> Gilles Chanteperdrix kirjoitti:
> > It means looking at the doc, if there are no anomalies, like warnings,
> > parsing errors of doxygen, or typos in the text. Usually takes an hour
> > or two. I admit I am not fast, but I think it would take some time for
> > Philippe
Heikki Lindholm wrote:
> Gilles Chanteperdrix kirjoitti:
> Hehe. So Philippe's machine would choke, if it had to generate the docs,
> too(?) And since most(?) of the docs comes from the sources, you don't
> actually edit them by hand now do you? So what does maintaining mean here?
Means proo
Gilles Chanteperdrix kirjoitti:
Heikki Lindholm wrote:
> Gilles Chanteperdrix kirjoitti:
> > Heikki Lindholm wrote:
> > > Gilles Chanteperdrix kirjoitti:
> > > Indeed. But this is the special attention I'm talking about ;) I'm still
> > > not convinced about the "need 'em for the release
attached patch gives xeno-config a --verbose option, ie:
soekris:/usr/realtime/2.6.13-ski6-v1/bin# xeno-config --v
xeno-config --verbose
--version="2.0"
--cc="gcc"
--cross-compile=""
--arch="i386"
--subarch=""
--prefix="/usr/realtime/2.6.13-ski6-v1"
--config="/usr/realtime/2.
Gilles Chanteperdrix kirjoitti:
Heikki Lindholm wrote:
> Gilles Chanteperdrix kirjoitti:
> Indeed. But this is the special attention I'm talking about ;) I'm still
> not convinced about the "need 'em for the release" reasoning. Let's put
> it this way: what trouble would it bring, if we had
Philippe Gerum kirjoitti:
Heikki Lindholm wrote:
Hello,
As people following powerpc kernel mailing lists probably know, the
Linux "ppc" and "ppc64" architectures are merging into a single
"powerpc" arch. I think the same should be done to fusion.
Agreed. Let's closely follow the "natural"
It would seem
quite easy and there's already lots of redundant code there, but
possible problems arise from being able to work with both the old
unmerged kernels and the future merged arch kernels.
Would the issues be located at the Adeos level, or would this leak to
Xeno's arch-dep layer?
Gilles Chanteperdrix kirjoitti:
Heikki Lindholm wrote:
> Gilles Chanteperdrix kirjoitti:
> > Heikki Lindholm wrote:
> > > Hi,
> > >
> > > One thing that always bothered my in fusion cvs: why do the generated
> > > docs have to be in the cvs/svn? Why not just let them be... well...
>
Heikki Lindholm wrote:
> Hi,
>
> One thing that always bothered my in fusion cvs: why do the generated
> docs have to be in the cvs/svn? Why not just let them be... well...
> generated?
The real answer is that if you do not "svn checkout" the "doc" directory,
Xenomai build system should co
Heikki Lindholm wrote:
Hello,
As people following powerpc kernel mailing lists probably know, the
Linux "ppc" and "ppc64" architectures are merging into a single
"powerpc" arch. I think the same should be done to fusion.
Agreed. Let's closely follow the "natural" development path of the kern
Dmitry Adamushko wrote:
On 10/10/05, Philippe Gerum <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:
As you noticed below, the point is that this feature should be active for
kernel-based code only; for user-space, we're toast: typical chicken-and-egg
problem since we need the registry to c
Heikki Lindholm wrote:
> Hi,
>
> One thing that always bothered my in fusion cvs: why do the generated
> docs have to be in the cvs/svn? Why not just let them be... well...
> generated?
Because it allows the releases to be done taking the docs from the
generated dir instead of generating t
Hi,
One thing that always bothered my in fusion cvs: why do the generated
docs have to be in the cvs/svn? Why not just let them be... well...
generated?
-- Heikki Lindholm
Philippe Gerum wrote:
Dmitry Adamushko wrote:
As you noticed below, the point is that this feature should be
active for
kernel-based code only; for user-space, we're toast: typical
chicken-and-egg
problem since we need the registry to cross the space boundaries but
the
registry requires a na
On 10/10/05, Philippe Gerum <[EMAIL PROTECTED]> wrote:
> Dmitry Adamushko wrote:
> >>As you noticed below, the point is that this feature should be active for
> >>kernel-based code only; for user-space, we're toast: typical chicken-and-egg
> >>problem since we need the registry to cross the space b
33 matches
Mail list logo
