On 08/05/06, Gilles Chanteperdrix [EMAIL PROTECTED] wrote:
Jan Kiszka wrote:
Likely I did not yet get the full picture: What prevents using another
adeos per-task key for this?
We would need a per-task key for every skin that needs a per-process
data, but more importantly, we would need to
Wolfgang Grandegger wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
[Daniel, I put you in the CC as you showed some interest in this topic.]
as I indicated a some weeks ago, I had a closer look at the code the
user space libs currently produce (on x86). The following considerations
are
Dmitry Adamushko wrote:
On 08/05/06, Gilles Chanteperdrix [EMAIL PROTECTED] wrote:
Jan Kiszka wrote:
Likely I did not yet get the full picture: What prevents using another
adeos per-task key for this?
We would need a per-task key for every skin that needs a per-process
Gilles Chanteperdrix wrote:
These patches are not ready for inclusion, they are not tested
yet.
The attached versions are tested. I still wonder if handling this in
shadow.c is the right solution, or if there should be an xnppd_set call
that could be called from within the skins event
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
These patches are not ready for inclusion, they are not tested
yet.
The attached versions are tested. I still wonder if handling this in
shadow.c is the right solution, or if there should be an xnppd_set call
that could be called from
Jim Cromie wrote:
attached patch corrects a mistake in rev 985, which chmod'd a read-only
file,
even if it was a symlink from a kernel-tree cloned with lndir.
This resulted in a bad original tree for use in building vanilla kernels.
with patch, script renames the symlink, copies it to the
Jim Cromie wrote:
Going thru xenomai Kconfig again, some observations/uncertainties came up.
I'll make a patch, given feedback.
XENO_OPT_TIMING_PERIODIC
Aperiodic mode provides for non-constant delays between timer ticks,
the wording here (non-constant delays) left me momentarily wondering
