From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <52AF1C51.3040400@siemens.com> Date: Mon, 16 Dec 2013 16:29:21 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <52AE0F6D.10007@xenomai.org> <52AE17FC.4070200@xenomai.org> <52AF1730.6010200@siemens.com> <52AF1976.2080605@xenomai.org> In-Reply-To: <52AF1976.2080605@xenomai.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Xenomai] Reworking file descriptors List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Xenomai 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