Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> Redone the check here on a Centrino 1.6Mhz, and still have roughly
x20 > improvement (a bit better actually). I'm using Debian/sarge
gcc 3.3.5.
I think I remember that Pentium M has a much shorter mull instruction
th
Jim Cromie wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> Redone the check here on a Centrino 1.6Mhz, and still have roughly
x20 > improvement (a bit better actually). I'm using Debian/sarge
gcc 3.3.5.
I think I remember that Pentium M has a much shorte
Philippe Gerum wrote:
> Jim Cromie wrote:
>> Philippe Gerum wrote:
>>
>>> Gilles Chanteperdrix wrote:
>>>
Philippe Gerum wrote:
> Redone the check here on a Centrino 1.6Mhz, and still have
roughly x20 > improvement (a bit better actually). I'm using
Debian/sarge gcc 3.3.5.
>>>
Niklaus Giger wrote:
> Is it okay to submit such a patch, which mixes a different test cases or
> shall I submit the patches in smaller pieces? Should the test that I put
> into
> the procedure msgDuringInt better be inlined? Or should I add a new file for
> these tests?
I think it is a
When using xenomai trunk, it appears that /proc/xenomai is no longer a
directory but a file returning "0".
--
Gilles Chanteperdrix.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/l
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jim Cromie wrote:
>>> Philippe Gerum wrote:
>>>
Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > Redone the check here on a Centrino 1.6Mhz, and still have
> roughly x20 > improvement (a bit better actually). I'm using
Gilles Chanteperdrix wrote:
When using xenomai trunk, it appears that /proc/xenomai is no longer a
directory but a file returning "0".
Check your recent changes for giving the nucleus a regular syscall
table. I would not be surprised of some side-effect there. i.e.
something going on with th
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > When using xenomai trunk, it appears that /proc/xenomai is no longer a
> > directory but a file returning "0".
> >
>
> Check your recent changes for giving the nucleus a regular syscall
> table. I would not be surprised of some side-
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > When using xenomai trunk, it appears that /proc/xenomai is no longer a
> > directory but a file returning "0".
> >
>
> Check your recent changes for giving the nucleus a regular syscall
> table. I would
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > When using xenomai trunk, it appears that /proc/xenomai is no
longer a
> > directory but a file returning "0".
> > > > Check your recent changes for giving the nucleus a regular
sy
Philippe Gerum wrote:
> This said, the other option would be to move the call to
> xnshadow_mount() from the xnarch_init() to __xeno_sys_init() in a
> kernel-only section, just after xnpod_init_proc() has returned. There is
> nothing done in the arch-layer for any architecture that would pre
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> This said, the other option would be to move the call to
> xnshadow_mount() from the xnarch_init() to __xeno_sys_init() in a
> kernel-only section, just after xnpod_init_proc() has returned. There is
> nothing done in the arch-layer for a
Am Mittwoch, 14. Juni 2006 15:23 schrieb Gilles Chanteperdrix:
> Niklaus Giger wrote:
> > Is it okay to submit such a patch, which mixes a different test cases
> > or shall I submit the patches in smaller pieces? Should the test that I
> > put into the procedure msgDuringInt better be inlined?
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > This said, the other option would be to move the call to
> > > xnshadow_mount() from the xnarch_init() to __xeno_sys_init() in a
> > > kernel-only section, just after xnpod_init_proc() has returned. There
Philippe Gerum wrote:
Jan Kiszka wrote:
Jim Cromie wrote:
Niklaus Giger wrote:
Am Freitag, 26. Mai 2006 15:52 schrieb Jan Kiszka:
Niklaus Giger wrote:...
If anybody has a working target with a Xenomai + BusyBox
combination and
would be willing to test drive my changes, I would apprec
hi Jan, everyone,
Ive worked up a patchset to add a GPIO driver for the chip on my mobo.
I adapted an existing one, drivers/char/scx200_gpio,
and created drivers/char/pc8736x_gpio
When doing this, I _oversimplified_ my problem by disregarding RTDM,
and Im hoping I can just _retrofit_ as needed.
hi Jan, everyone,
Separately..
In this GPIO work, I concluded that I needed to add a sysfs interface
to my driver, in order to better fit with LKML expectations.
Sysfs GPIO representation of Hardware (v0.2)
(v0.1 went to lm-sensors ML, v0.2 to kernelnewbies ML)
We need a standard rep for GP
17 matches
Mail list logo
