All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kim De Mey <kim.demey@gmail.com>
To: xenomai@xenomai.org
Subject: [Xenomai] [PATCH 0 of 3] Xenomai-forge: Initial implementation of registry for pSOS
Date: Tue, 15 Oct 2013 10:50:36 +0200	[thread overview]
Message-ID: <patchbomb.1381827036@devws164.be.alcatel-lucent.com> (raw)

This patch set adds an initial implementation of registry for pSOS 
tasks, semaphores and queues. It is similar as the already existing 
vxworks implementation but with more output data.

Important to mention is that the "size" parameter in the read function
is not used (it is also not used in the vxworks implementation).
This will be an issue if the data to output is larger than the buffer 
used. This is now possible to happen as I added messages in the queue 
read function and timers in the task read function. In that case an 
implementation which uses size & offset is necessary.

I am busy implementing a second patch that does this. 
It creates a local buffer which is filled with the data on an "open" 
call. A pointer to the local buffer is saved in the fuse_file_info->fh
field (requires FUSE version >=  2.5). A read will then just read from 
the local buffer with offset and size given. A release is also needed to
free the buffer.

However while I continue with this I would like to know whether you see
this as the right way to go. Does the data I output (and the format) in
this patch make sense to you? And in case yes, shall I continue to 
implement the second patch as described above or are there other views
on this? It might be a bit vague without actually seeing code but if you
want I can already submit a preliminary version of the second patch.

Kim


 include/psos/psos.h |    2 ++
 lib/psos/queue.c    |   77 ++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++
 lib/psos/queue.h    |    1 +
 lib/psos/sem.c      |   43 +++++++++++++++++++++++++++++++++++++++++++
 lib/psos/sem.h      |    1 +
 lib/psos/task.c     |  115 ++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/psos/task.h     |    4 ++++
 7 files changed, 243 insertions(+), 0 deletions(-)


             reply	other threads:[~2013-10-15  8:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15  8:50 Kim De Mey [this message]
2013-10-15  8:50 ` [Xenomai] [PATCH 1 of 3] Initial implementation registry pSOS task Kim De Mey
2013-10-15  8:50 ` [Xenomai] [PATCH 2 of 3] Initial implementation registry pSOS semaphore Kim De Mey
2013-10-22 16:54   ` Kim De Mey
2013-10-15  8:50 ` [Xenomai] [PATCH 3 of 3] Initial implementation registry pSOS queue Kim De Mey
2013-10-19 17:37 ` [Xenomai] [PATCH 0 of 3] Xenomai-forge: Initial implementation of registry for pSOS Philippe Gerum
2013-10-19 18:56   ` Ronny Meeus
2013-10-22 16:45     ` Kim De Mey
2013-10-22 17:06       ` Philippe Gerum
2013-10-22 18:18         ` Kim De Mey
2013-10-24  8:28           ` Kim De Mey
2013-10-24  9:00             ` Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=patchbomb.1381827036@devws164.be.alcatel-lucent.com \
    --to=kim.demey@gmail.com \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.