Re: [Xenomai-core] RTDM fd support.

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]

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.

The only way around this is to implement at least a prototype. That
takes some time. And until this isn't done, we cannot release 2.5. Or we
have to set this limitation in stone and live with it until 3.x does it
correctly.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]