Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer we want to dereference; we'd better
keep
this unpreemptable, although it's
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer we want to
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer we want to dereference; we'd better
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer
Here comes the complete series of patches to improve the Xenomai
registry. #1, #5, and #6 are resends of already posted patches, the
middle part is fresh from the editor. The series reduces overhead
and simplifies the registry code. Overall diffstat:
include/asm-generic/hal.h | 10 +-
See Changelog.
---
ChangeLog |6 ++
ksrc/nucleus/registry.c | 44 +---
2 files changed, 19 insertions(+), 31 deletions(-)
Index: b/ChangeLog
===
--- a/ChangeLog
+++
Hook up xnobject directly to the hash table instead of establishing
dynamically created xnobjhash redirections.
---
include/nucleus/registry.h | 10 +-
ksrc/nucleus/registry.c| 73 +++--
2 files changed, 33 insertions(+), 50 deletions(-)
Some customer ran into the problem of lacking registry slots without
prior warning. We are lacking some report mechanism, specifically for
unexported (anonymous) entries (every native user object requires one
for its handle).
This patch introduces /proc/xenomai/registry_usage in the form
No need to add anonymous registry entries with pseudo names to the hash
table - no one will look them up anyway. Reduces hash key collisions for
named objects.
---
ChangeLog |3 +++
ksrc/nucleus/registry.c | 34 ++
2 files changed, 25
Jan Kiszka wrote:
BTW, I'm also preparing a patch to overcome hash chain registrations for
anonymous (handle-only) objects as I need more of them (one for each
thread) for fast mutexes - to avoid fiddling with kernel pointers in
userland.
Ok. You will have a problem mangling a registry handle
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
BTW, I'm also preparing a patch to overcome hash chain registrations for
anonymous (handle-only) objects as I need more of them (one for each
thread) for fast mutexes - to avoid fiddling with kernel
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
BTW, I'm also preparing a patch to overcome hash chain registrations for
anonymous (handle-only) objects as I need more of them (one for each
thread) for fast mutexes - to
Jan Kiszka wrote:
OK, this all sounds like fast-lock awareness would have to be taught
to xnsynch first. But that would also open the chance to teach it
that handles are stored inside the lock word, no pointers.
That could be done too... But that would be really a critical change,
with updates
Jan Kiszka wrote:
Here comes the complete series of patches to improve the Xenomai
registry. #1, #5, and #6 are resends of already posted patches, the
middle part is fresh from the editor. The series reduces overhead
and simplifies the registry code. Overall diffstat:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
BTW, I'm also preparing a patch to overcome hash chain registrations for
anonymous (handle-only) objects as I need more of them (one for each
thread) for fast mutexes - to avoid fiddling with kernel pointers in
userland.
Ok. You will have a
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Here comes the complete series of patches to improve the Xenomai
registry. #1, #5, and #6 are resends of already posted patches, the
middle part is fresh from the editor. The series reduces overhead
and simplifies the registry code. Overall
Jan Kiszka wrote:
Some customer ran into the problem of lacking registry slots without
prior warning. We are lacking some report mechanism, specifically for
unexported (anonymous) entries (every native user object requires one
for its handle).
This patch introduces
Philippe Gerum wrote:
Jan Kiszka wrote:
Some customer ran into the problem of lacking registry slots without
prior warning. We are lacking some report mechanism, specifically for
unexported (anonymous) entries (every native user object requires one
for its handle).
This patch introduces
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Some customer ran into the problem of lacking registry slots without
prior warning. We are lacking some report mechanism, specifically for
unexported (anonymous) entries (every native user object requires one
for its handle).
This
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Some customer ran into the problem of lacking registry slots without
prior warning. We are lacking some report mechanism, specifically for
unexported (anonymous) entries (every native user object requires one
[ Trying the keep my queue short... ]
This version, posted earlier already, should address all remarks brought
up. OK to commit?
---
include/nucleus/intr.h | 25 +++-
ksrc/nucleus/intr.c| 76 +++--
ksrc/nucleus/module.c | 47
21 matches
Mail list logo
