All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: Xenomai core <Xenomai-core@domain.hid>
Subject: Re: [Xenomai-core] RTDM fd support.
Date: Fri, 02 Oct 2009 18:33:05 +0200	[thread overview]
Message-ID: <4AC62B41.3050404@domain.hid> (raw)
In-Reply-To: <4AC62804.7090903@domain.hid>

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Hi Jan,
>>
>> from discussions on the mailing list, it seems that we are going to need
>> that unified file descriptors thing. However, since everybody wants
>> 2.5.0 to be released ASAP, we should try to think about any changes for
>> this support which would break the ABI, do them now, and keep the rest
>> for later.
>>
>> One such problem is the translation which currently exists between rtdm
>> file descriptors and descriptors passed to the posix skin, by adding
>> 1024 - 128. So, I propose to fix this issue.
>>
>> The idea Philippe had, and which I tend to agree to, was, in case of
>> open/socket/accept, to open("/dev/null"), and use an association table
>> somewhere to associate with the kernel-space descriptor number. Since
>> we are at it, this association table could in fact be the file
>> descriptor table, which we would put in the core skin ppd. The actual
>> data structure should be sparse, a linked list does not scale, so,
>> probably a hash would do. (I could also propose a solution based on avl
>> trees, but their implementation is not nearly as simple).
>>
>> Additionnally, this would allow our open/socket to conform to posix
>> which states that open should return the lowest free file descriptor.
>>
>> Should I propose a patch in that direction? Do you see any other
>> possible cause of ABI breakage when we migrate to an unified file
>> descriptors structure?
> 
> Right now this sounds like a plan - but I don't feel 100% comfortable to
> predict that we will get along with it. Converting some skin-specific
> service to a generic one involves quite a lot of refactoring. It is not
> really unlikely that we define some ABI now that will later turn out to
> be insufficient for what we want to achieve.

For the posix skin, I can live with a two hops solution right now, and
implement the one-hop solution later.

user-space fd
      |
      | core skin fd table
      v
kernel-space fd
      |
      | posix skin registry
      v
actual object

If we do this, there is not much re-factoring involved.

The question really boils down to whether you accept this solution for
the rtdm skin too.

-- 
					    Gilles.


  reply	other threads:[~2009-10-02 16:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-02 15:42 [Xenomai-core] RTDM fd support Gilles Chanteperdrix
2009-10-02 16:19 ` Jan Kiszka
2009-10-02 16:33   ` Gilles Chanteperdrix [this message]
2009-10-02 19:16     ` Jan Kiszka
2009-10-02 20:04       ` Gilles Chanteperdrix
2009-10-02 20:15         ` Jan Kiszka
2009-10-02 20:18           ` Gilles Chanteperdrix
2009-10-02 20:26             ` Jan Kiszka
2009-10-02 20:45               ` Gilles Chanteperdrix
2009-10-03 17:39                 ` Jan Kiszka

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=4AC62B41.3050404@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=Xenomai-core@domain.hid \
    --cc=jan.kiszka@domain.hid \
    /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.