[Xenomai] Reworking file descriptors

[Xenomai] Reworking file descriptors

[Gilles Chanteperdrix]

Hi Jan,

I have starting reworking the posix skin on forge to use the cobalt
registry instead of the ad-hoc registry it currently uses. The next step
for that work is to convert the file descriptors, offering a unified
access with select to posix skin message queues and rtdm drivers, and
working correctly with fork().

I have a clear idea on how I would do it for the posix message queues
only. Just as I did for the semaphores, I would implement a hash table,
where the file descriptor structures are indexed by the user-space file
descriptor (obtained with open(/dev/null) for instance, so that xenomai
file descriptors follow the posix specification, and use the smallest
available descriptor), and the mm structure.

However, RTDM allows opening file descriptors in kernel-space, so it
would break my implementation, because we can use NULL or &init_mm as
the mm key, but what would we use as the file descriptor index?

Any idea is welcome.
Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Reworking file descriptors

[Gilles Chanteperdrix]

On 12/15/2013 09:22 PM, Gilles Chanteperdrix wrote:
> 
> Hi Jan,
> 
> I have starting reworking the posix skin on forge to use the cobalt
> registry instead of the ad-hoc registry it currently uses. The next step
> for that work is to convert the file descriptors, offering a unified
> access with select to posix skin message queues and rtdm drivers, and
> working correctly with fork().
> 
> I have a clear idea on how I would do it for the posix message queues
> only. Just as I did for the semaphores, I would implement a hash table,
> where the file descriptor structures are indexed by the user-space file
> descriptor (obtained with open(/dev/null) for instance, so that xenomai
> file descriptors follow the posix specification, and use the smallest
> available descriptor), and the mm structure.
> 
> However, RTDM allows opening file descriptors in kernel-space, so it
> would break my implementation, because we can use NULL or &init_mm as
> the mm key, but what would we use as the file descriptor index?

Crazy ideas include calling xnregistry_enter and using the returned
handler as file descriptor in kernel-space, but that would give a
different way to get the file descriptor structure for kernel-space and
user-space.


-- 
                                                                Gilles.

Re: [Xenomai] Reworking file descriptors

[Jan Kiszka]

On 2013-12-15 21:58, Gilles Chanteperdrix wrote:
> On 12/15/2013 09:22 PM, Gilles Chanteperdrix wrote:
>>
>> Hi Jan,
>>
>> I have starting reworking the posix skin on forge to use the cobalt
>> registry instead of the ad-hoc registry it currently uses. The next step
>> for that work is to convert the file descriptors, offering a unified
>> access with select to posix skin message queues and rtdm drivers, and
>> working correctly with fork().
>>
>> I have a clear idea on how I would do it for the posix message queues
>> only. Just as I did for the semaphores, I would implement a hash table,
>> where the file descriptor structures are indexed by the user-space file
>> descriptor (obtained with open(/dev/null) for instance, so that xenomai
>> file descriptors follow the posix specification, and use the smallest
>> available descriptor), and the mm structure.
>>
>> However, RTDM allows opening file descriptors in kernel-space, so it
>> would break my implementation, because we can use NULL or &init_mm as
>> the mm key, but what would we use as the file descriptor index?
> 
> Crazy ideas include calling xnregistry_enter and using the returned
> handler as file descriptor in kernel-space, but that would give a
> different way to get the file descriptor structure for kernel-space and
> user-space.

I'm not sure if I got the idea yet: User space would obtain the file
descriptor index itself, via opening /dev/null, and provide this index
together with the open or socket request to the kernel, right? So far we
did the index management inside the RTDM layer, reusing Linux for it
would be the major change.

Then the only difference for kernel originated open is that there is no
Linux-provided source of file descriptor indexes. We will need a
separate one in RTDM, just like so far. The difference will be that this
one, likely again a simple bitmap, will serve in-kernel users only.

Reading your proposal again, I see you mentioning user space file
descriptor structures. Where do they come from? What are their purpose?
We didn't have a need for them so far, why now?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Reworking file descriptors

[Gilles Chanteperdrix]

On 12/16/2013 04:07 PM, Jan Kiszka wrote:
> On 2013-12-15 21:58, Gilles Chanteperdrix wrote:
>> On 12/15/2013 09:22 PM, Gilles Chanteperdrix wrote:
>>>
>>> Hi Jan,
>>>
>>> I have starting reworking the posix skin on forge to use the cobalt
>>> registry instead of the ad-hoc registry it currently uses. The next step
>>> for that work is to convert the file descriptors, offering a unified
>>> access with select to posix skin message queues and rtdm drivers, and
>>> working correctly with fork().
>>>
>>> I have a clear idea on how I would do it for the posix message queues
>>> only. Just as I did for the semaphores, I would implement a hash table,
>>> where the file descriptor structures are indexed by the user-space file
>>> descriptor (obtained with open(/dev/null) for instance, so that xenomai
>>> file descriptors follow the posix specification, and use the smallest
>>> available descriptor), and the mm structure.
>>>
>>> However, RTDM allows opening file descriptors in kernel-space, so it
>>> would break my implementation, because we can use NULL or &init_mm as
>>> the mm key, but what would we use as the file descriptor index?
>>
>> Crazy ideas include calling xnregistry_enter and using the returned
>> handler as file descriptor in kernel-space, but that would give a
>> different way to get the file descriptor structure for kernel-space and
>> user-space.
>
> I'm not sure if I got the idea yet: User space would obtain the file
> descriptor index itself, via opening /dev/null, and provide this index
> together with the open or socket request to the kernel, right? So far we
> did the index management inside the RTDM layer, reusing Linux for it
> would be the major change.

Yes but:
- would allow to have the same file descriptor index used in several 
process, which a must to fix the issue with file descriptors and fork;
- would allow to respect posix, and return the smallest available 
integer, instead of a random integer between 896 and 1023.

>
> Then the only difference for kernel originated open is that there is no
> Linux-provided source of file descriptor indexes. We will need a
> separate one in RTDM, just like so far. The difference will be that this
> one, likely again a simple bitmap, will serve in-kernel users only.
>
> Reading your proposal again, I see you mentioning user space file
> descriptor structures. Where do they come from? What are their purpose?
> We didn't have a need for them so far, why now?

We have them for message queues. I believe RTDM has the equivalent with 
what it calls the "context". It is just a structure which will contain 
data associated with the file descriptor, the only data needed for the 
message queues for instance is the "open" flags, allowing mq_receive to 
know whether if the corresponding mq_open was called with O_RD or not, 
to be able to return -EPERM, and the pointer or registry handle to the 
corresponding message queue object itself (the "file"). It also contains 
the holder(s) necessary for the book-keeping, like making it available 
through a hash table, or closing it automatically upon process termination.

-- 
					    Gilles.

Re: [Xenomai] Reworking file descriptors

[Jan Kiszka]

On 2013-12-16 16:17, Gilles Chanteperdrix wrote:
> On 12/16/2013 04:07 PM, Jan Kiszka wrote:
>> On 2013-12-15 21:58, Gilles Chanteperdrix wrote:
>>> On 12/15/2013 09:22 PM, Gilles Chanteperdrix wrote:
>>>>
>>>> Hi Jan,
>>>>
>>>> I have starting reworking the posix skin on forge to use the cobalt
>>>> registry instead of the ad-hoc registry it currently uses. The next
>>>> step
>>>> for that work is to convert the file descriptors, offering a unified
>>>> access with select to posix skin message queues and rtdm drivers, and
>>>> working correctly with fork().
>>>>
>>>> I have a clear idea on how I would do it for the posix message queues
>>>> only. Just as I did for the semaphores, I would implement a hash table,
>>>> where the file descriptor structures are indexed by the user-space file
>>>> descriptor (obtained with open(/dev/null) for instance, so that xenomai
>>>> file descriptors follow the posix specification, and use the smallest
>>>> available descriptor), and the mm structure.
>>>>
>>>> However, RTDM allows opening file descriptors in kernel-space, so it
>>>> would break my implementation, because we can use NULL or &init_mm as
>>>> the mm key, but what would we use as the file descriptor index?
>>>
>>> Crazy ideas include calling xnregistry_enter and using the returned
>>> handler as file descriptor in kernel-space, but that would give a
>>> different way to get the file descriptor structure for kernel-space and
>>> user-space.
>>
>> I'm not sure if I got the idea yet: User space would obtain the file
>> descriptor index itself, via opening /dev/null, and provide this index
>> together with the open or socket request to the kernel, right? So far we
>> did the index management inside the RTDM layer, reusing Linux for it
>> would be the major change.
> 
> Yes but:
> - would allow to have the same file descriptor index used in several
> process, which a must to fix the issue with file descriptors and fork;
> - would allow to respect posix, and return the smallest available
> integer, instead of a random integer between 896 and 1023.

Not voting against this change. RTDM's approach once started off with
the goal to be simple and self-contained. Requirements were extended
over the time.

> 
>>
>> Then the only difference for kernel originated open is that there is no
>> Linux-provided source of file descriptor indexes. We will need a
>> separate one in RTDM, just like so far. The difference will be that this
>> one, likely again a simple bitmap, will serve in-kernel users only.
>>
>> Reading your proposal again, I see you mentioning user space file
>> descriptor structures. Where do they come from? What are their purpose?
>> We didn't have a need for them so far, why now?
> 
> We have them for message queues. I believe RTDM has the equivalent with
> what it calls the "context". It is just a structure which will contain
> data associated with the file descriptor, the only data needed for the
> message queues for instance is the "open" flags, allowing mq_receive to
> know whether if the corresponding mq_open was called with O_RD or not,
> to be able to return -EPERM, and the pointer or registry handle to the
> corresponding message queue object itself (the "file"). It also contains
> the holder(s) necessary for the book-keeping, like making it available
> through a hash table, or closing it automatically upon process termination.

For sure, also RTDM needs a descriptor data structure in kernel space. I
guess I misinterpreted your words that there are also structures *in*
user space, not just *for* it.

OK, so the callers of open and socket - user space or kernel space -
will now have to provide an ID along with that request. This ID has to
be unique within their namespaces, may it be a process or the whole
kernel for drivers. For user space, ID allocation maps to POSIX file
descriptor allocation. For kernel space, we are totally free to use a
different source like a simple bitmap, the file descriptor data
structure address or whatever is convenient. But it will be different,
naturally.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux