Re: [Xenomai-core] RTDM fd support.

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

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Then please summarize again what you want change from the user's POV (fd
>> range and arbitration, I guess, but also their scope?)
> 
> Basically, when going from user-space to kernel-space, instead of a
> simple translation, currently done with an addition in user-space for
> most services, in kernel-space for select, there is a hash lookup, done
> in kernel-space.
> 
>  and what impact
>> that will have on the library and kernel ABIs.
> 
> The impact on the ABI is that we no longer do the translation using
> addition/substraction. If we broke all at once in version 2.5.x, we
> could not run a 2.5.x-1 user-space support that does the
> addition/substraction, with a 2.5.x kernel-space support which has the
> unified file descriptors abstraction.
> 
>  What would be part of
>> step 1, what of step 2 later in 2.5.x?
> 
> Step 1 is adding the fdtable, use it in the rtdm and posix skin before
> returning a fd to user-space, and when getting an fd from user-space.
> Remove the translation by addition/substraction in the rtdm part of
> libpthread_rt.

I assume this mapping will already make user-visible fds process-local,
right?

BTW, one downside of pushing the translation into the kernel part of the
skins is that POSIX borderline threads will pay via an additional
syscall + a futile lookup in the Xenomai fdtable. So far we can dispatch
 very cheaply. On the other hand, POSIX users who care about performance
could also user __real_* or avoid the automatic wrapping.

> 
> Step 2 is replacing the rtdm and posix registries with an unified fd
> support based on the fdtable, the real kernel-space file descriptors (I
> mean, the one which really belong to a kernel-space app) would be
> implemented using a global fdtable. Duplicate the fdtable at fork, etc...
> 

OK, if you are willing to draft a prototype for step 1, I'm open to
discuss it. My requirements would be:
 - per-process fdtables (and locks) for the first level lookup
 - the second level lookup should be limited to device creation; simply
   keep a permanent reference to the rtdm_context in the fdtable

Jan


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