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

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...


Xenomai-core mailing list

Reply via email to