Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Gilles Chanteperdrix wrote:
>  > > Jan Kiszka wrote:
>  > >  > Gilles Chanteperdrix wrote:
>  > >  > > Jan Kiszka wrote:
>  > >  > >  > Gilles Chanteperdrix wrote:
>  > >  > >  > > Would not it be simpler to put a pointer to the task_struct ? After all,
>  > >  > >  > > it already has a pid, comm and mm, and a file descriptor will not
>  > >  > >  > > survive a task_struct thanks to automatic closing of file descriptors.
>  > >  > >  > 
>  > >  > >  > Hmm, hmm, hmmmm... Sounds reasonable, should be safe.
>  > >  > > 
>  > >  > > Actually no, we can not do that because a task_struct may well disappear
>  > >  > > and the rtdm_process continue to exist as long as another thread uses the
>  > >  > > same mm.
>  > >  > 
>  > >  > Because we cleanup on mm exit, not task exit, right? OK, looks like I 
>  > >  > originally spent a few more thoughts than this time :-/.
>  > >  > 
>  > >  > > 
>  > >  > >  > 
>  > >  > >  > > 
>  > >  > >  > >  Could you
>  > >  > >  > >  > live without the check until we have per-process fd tabled, or was it
>  > >  > >  > >  > essential for the select thing?
>  > >  > >  > > 
>  > >  > >  > > An application which I ported to Xenomai (and which uses the select
>  > >  > >  > > call) closes all file descriptors in a for loop. The purpose of this
>  > >  > >  > > loop is, I guess, to avoid leaving a file descriptor opened that was
>  > >  > >  > > passed through exec.
>  > >  > >  > 
>  > >  > >  > OK.
>  > >  > >  > 
>  > >  > >  > So, will you change rtdm_process too? Thanks.
>  > >  > > 
>  > >  > > I commited the select support, without any change to rtdm_context_get or
>  > >  > > rtdm_process. So, now, how do you prefer this to be fixed, by adding an
>  > >  > > mm struct to the rtdm_process struct ? By the way, after thinking about
>  > >  > > it I can live without this fix: I just have to stop the loop closing
>  > >  > > file descriptors at 768, so that it will not try to close RTDM file
>  > >  > > descriptors.
>  > >  > 
>  > >  > If you can live with it, I would vote for fixing it by the intended 
>  > >  > redesign via per-process fds.
>  > > 
>  > > Ok.
>  > > 
>  > >  > 
>  > >  > > 
>  > >  > > While commiting the support for select, I also had a dependency problem
>  > >  > > in Kconfig: when support for posix select is enabled the posix module
>  > >  > > uses a function defined in the RTDM module. So, there is one invalid
>  > >  > > configuration: posix built-in with support for select and rtdm built as
>  > >  > > a module. I could not find a way to express this condition in the
>  > >  > > Kconfig language, so I just made a comment depend on this condition, but
>  > >  > > would be happy if anyone found a better solution.
>  > >  > 
>  > >  > I would say:
>  > >  > 
>  > >  > config POSIX
>  > >  > 	select RTDM if OPT_SELECT
>  > > 
>  > > But in this case, I can not have posix with select and without rtdm.
>  > 
>  > Then you need to isolate those services that POSIX needs from RTDM. The 
>  > above just expresses the dependency you described. 
> 
> Then I was wrong in what I described: the problem is that if posix is
> built-in and RTDM is enabled, then RTDM must be built-in.

That should be covered by the kconfig rule automatically.

> 
> In the end this just 
>  > shows that we have to define the common fd-ground for both skins in the 
>  > core.
> 
> I also have the choice of defining the service needed
> (rt_dev_select_bind) as a callback in the posix module, the RTDM module
> setting this callback when loaded (like what the rtcap module does with
> rtnet). But I wanted something simple, so I aimed at Kconfig stuff.
> 

If you can live with the callback being NULL, you could also perfectly 
wrap some ifdef CONFIG_...RTDM[_MODULE] around the current invocations. 
Then you don't need the dependency above. I think I have to look at the 
code...

Jan