[Xenomai] Retrieval of user fd from struct rtdm_fd

[Xenomai] Retrieval of user fd from struct rtdm_fd

[Sebastian Smolorz]

Hello Philippe or Jan,

I need to retrieve the socket file descriptor from an RTDM device driver 
routine. From what I have seen there is no simple way to obtain this int 
value from struct rtdm_fd. I have identified three possible ways to do 
this, all of them necessitate modification of Xenomai code outside the 
driver:

1. Iterate over the rb_tree rtdm_fd->owner->fds by means of the macro 
xntree_for_each_entry(pos, root, member). For this macro to work the 
definition of struct rtdm_fd_index must be known to the driver which 
means that it would have to be moved from kernel/cobalt/rtdm/fd.c to 
e.g. include/cobalt/kernel/rtdm/fd.h.

2. Similar to 1. but offer a new function rtdm_fd_get_ufd(struct rtdm_fd 
*fd) in which the rb_tree is searched.

3. Introduce a new value "int ufd" in struct rtdm_fd for setting and 
getting the ufd directly (which would be overkill I suppose because the 
vast majority of drivers don't need it).

What do you think, which of the above would you prefer?

-- 
Sebastian

Re: [Xenomai] Retrieval of user fd from struct rtdm_fd

[Philippe Gerum]

On 10/14/2018 09:27 PM, Sebastian Smolorz wrote:
> Hello Philippe or Jan,
> 
> I need to retrieve the socket file descriptor from an RTDM device driver 
> routine.

Could you elaborate on the reason to need this?

-- 
Philippe.

Re: [Xenomai] Retrieval of user fd from struct rtdm_fd

[Sebastian Smolorz]

Philippe Gerum wrote:

> On 10/14/2018 09:27 PM, Sebastian Smolorz wrote:
> > Hello Philippe or Jan,
> > 
> > I need to retrieve the socket file descriptor from an RTDM device driver 
> > routine.
> 
> Could you elaborate on the reason to need this?

The rttcp driver was programmed to only accept one connection
and not create a new socket for it but instead use the existing
one. So rt_tcp_accept() returns its socket's fd number.

-- 
Sebastian

Re: [Xenomai] Retrieval of user fd from struct rtdm_fd

[Jan Kiszka]

On 14.10.18 21:27, Sebastian Smolorz wrote:
> Hello Philippe or Jan,
> 
> I need to retrieve the socket file descriptor from an RTDM device driver
> routine. From what I have seen there is no simple way to obtain this int
> value from struct rtdm_fd. I have identified three possible ways to do
> this, all of them necessitate modification of Xenomai code outside the
> driver:
> 
> 1. Iterate over the rb_tree rtdm_fd->owner->fds by means of the macro
> xntree_for_each_entry(pos, root, member). For this macro to work the
> definition of struct rtdm_fd_index must be known to the driver which
> means that it would have to be moved from kernel/cobalt/rtdm/fd.c to
> e.g. include/cobalt/kernel/rtdm/fd.h.
> 
> 2. Similar to 1. but offer a new function rtdm_fd_get_ufd(struct rtdm_fd
> *fd) in which the rb_tree is searched.
> 
> 3. Introduce a new value "int ufd" in struct rtdm_fd for setting and
> getting the ufd directly (which would be overkill I suppose because the
> vast majority of drivers don't need it).

OTOH, that structure is not really optimized for size. So I do not see why it 
shouldn't take yet another int, which would also be a faster API than the other 
options.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Retrieval of user fd from struct rtdm_fd

[Sebastian Smolorz]

Jan Kiszka wrote:

> On 14.10.18 21:27, Sebastian Smolorz wrote:
> > Hello Philippe or Jan,
> > 
> > I need to retrieve the socket file descriptor from an RTDM device driver
> > routine. From what I have seen there is no simple way to obtain this int
> > value from struct rtdm_fd. I have identified three possible ways to do
> > this, all of them necessitate modification of Xenomai code outside the
> > driver:
> > 
> > 1. Iterate over the rb_tree rtdm_fd->owner->fds by means of the macro
> > xntree_for_each_entry(pos, root, member). For this macro to work the
> > definition of struct rtdm_fd_index must be known to the driver which
> > means that it would have to be moved from kernel/cobalt/rtdm/fd.c to
> > e.g. include/cobalt/kernel/rtdm/fd.h.
> > 
> > 2. Similar to 1. but offer a new function rtdm_fd_get_ufd(struct rtdm_fd
> > *fd) in which the rb_tree is searched.
> > 
> > 3. Introduce a new value "int ufd" in struct rtdm_fd for setting and
> > getting the ufd directly (which would be overkill I suppose because the
> > vast majority of drivers don't need it).
> 
> OTOH, that structure is not really optimized for size. So I do not see why it 
> shouldn't take yet another int, which would also be a faster API than the other 
> options.

Correct. Nevertheless, we could mitigate the effect of this change by
surrounding the new ufd field with
#ifdef CONFIG_XENO_DRIVERS_NET_RTIPV4_TCP

-- 
Sebastian

Re: [Xenomai] Retrieval of user fd from struct rtdm_fd

[Philippe Gerum]

On 10/15/2018 03:17 PM, Sebastian Smolorz wrote:
> Jan Kiszka wrote:
> 
>> On 14.10.18 21:27, Sebastian Smolorz wrote:
>>> Hello Philippe or Jan,
>>>
>>> I need to retrieve the socket file descriptor from an RTDM device driver
>>> routine. From what I have seen there is no simple way to obtain this int
>>> value from struct rtdm_fd. I have identified three possible ways to do
>>> this, all of them necessitate modification of Xenomai code outside the
>>> driver:
>>>
>>> 1. Iterate over the rb_tree rtdm_fd->owner->fds by means of the macro
>>> xntree_for_each_entry(pos, root, member). For this macro to work the
>>> definition of struct rtdm_fd_index must be known to the driver which
>>> means that it would have to be moved from kernel/cobalt/rtdm/fd.c to
>>> e.g. include/cobalt/kernel/rtdm/fd.h.
>>>
>>> 2. Similar to 1. but offer a new function rtdm_fd_get_ufd(struct rtdm_fd
>>> *fd) in which the rb_tree is searched.
>>>
>>> 3. Introduce a new value "int ufd" in struct rtdm_fd for setting and
>>> getting the ufd directly (which would be overkill I suppose because the
>>> vast majority of drivers don't need it).
>>
>> OTOH, that structure is not really optimized for size. So I do not see why it 
>> shouldn't take yet another int, which would also be a faster API than the other 
>> options.
> 
> Correct. Nevertheless, we could mitigate the effect of this change by
> surrounding the new ufd field with
> #ifdef CONFIG_XENO_DRIVERS_NET_RTIPV4_TCP
> 

The core layer implementing RTDM fd is not supposed to depend on high
level remote features such as tcp protocol over rtnet.

Let's just add the missing info to rtdm_fd unconditionally, we are
talking about a few tenths of additional bytes in a typical Xenomai
system fitted with several MB of memory (likely less than what would be
needed to scan the fd tree to retrieve the same information btw).

-- 
Philippe.

Re: [Xenomai] Retrieval of user fd from struct rtdm_fd

[Jan Kiszka]

On 15.10.18 15:28, Philippe Gerum wrote:
> On 10/15/2018 03:17 PM, Sebastian Smolorz wrote:
>> Jan Kiszka wrote:
>>
>>> On 14.10.18 21:27, Sebastian Smolorz wrote:
>>>> Hello Philippe or Jan,
>>>>
>>>> I need to retrieve the socket file descriptor from an RTDM device driver
>>>> routine. From what I have seen there is no simple way to obtain this int
>>>> value from struct rtdm_fd. I have identified three possible ways to do
>>>> this, all of them necessitate modification of Xenomai code outside the
>>>> driver:
>>>>
>>>> 1. Iterate over the rb_tree rtdm_fd->owner->fds by means of the macro
>>>> xntree_for_each_entry(pos, root, member). For this macro to work the
>>>> definition of struct rtdm_fd_index must be known to the driver which
>>>> means that it would have to be moved from kernel/cobalt/rtdm/fd.c to
>>>> e.g. include/cobalt/kernel/rtdm/fd.h.
>>>>
>>>> 2. Similar to 1. but offer a new function rtdm_fd_get_ufd(struct rtdm_fd
>>>> *fd) in which the rb_tree is searched.
>>>>
>>>> 3. Introduce a new value "int ufd" in struct rtdm_fd for setting and
>>>> getting the ufd directly (which would be overkill I suppose because the
>>>> vast majority of drivers don't need it).
>>>
>>> OTOH, that structure is not really optimized for size. So I do not see why it
>>> shouldn't take yet another int, which would also be a faster API than the other
>>> options.
>>
>> Correct. Nevertheless, we could mitigate the effect of this change by
>> surrounding the new ufd field with
>> #ifdef CONFIG_XENO_DRIVERS_NET_RTIPV4_TCP
>>
> 
> The core layer implementing RTDM fd is not supposed to depend on high
> level remote features such as tcp protocol over rtnet.
> 
> Let's just add the missing info to rtdm_fd unconditionally, we are
> talking about a few tenths of additional bytes in a typical Xenomai
> system fitted with several MB of memory (likely less than what would be
> needed to scan the fd tree to retrieve the same information btw).
> 

Ack.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Retrieval of user fd from struct rtdm_fd

[Sebastian Smolorz]

Jan Kiszka wrote:

> On 15.10.18 15:28, Philippe Gerum wrote:
> > On 10/15/2018 03:17 PM, Sebastian Smolorz wrote:
> >> Jan Kiszka wrote:
> >>
> >>> On 14.10.18 21:27, Sebastian Smolorz wrote:
> >>>> Hello Philippe or Jan,
> >>>>
> >>>> I need to retrieve the socket file descriptor from an RTDM device driver
> >>>> routine. From what I have seen there is no simple way to obtain this int
> >>>> value from struct rtdm_fd. I have identified three possible ways to do
> >>>> this, all of them necessitate modification of Xenomai code outside the
> >>>> driver:
> >>>>
> >>>> 1. Iterate over the rb_tree rtdm_fd->owner->fds by means of the macro
> >>>> xntree_for_each_entry(pos, root, member). For this macro to work the
> >>>> definition of struct rtdm_fd_index must be known to the driver which
> >>>> means that it would have to be moved from kernel/cobalt/rtdm/fd.c to
> >>>> e.g. include/cobalt/kernel/rtdm/fd.h.
> >>>>
> >>>> 2. Similar to 1. but offer a new function rtdm_fd_get_ufd(struct rtdm_fd
> >>>> *fd) in which the rb_tree is searched.
> >>>>
> >>>> 3. Introduce a new value "int ufd" in struct rtdm_fd for setting and
> >>>> getting the ufd directly (which would be overkill I suppose because the
> >>>> vast majority of drivers don't need it).
> >>>
> >>> OTOH, that structure is not really optimized for size. So I do not see why it
> >>> shouldn't take yet another int, which would also be a faster API than the other
> >>> options.
> >>
> >> Correct. Nevertheless, we could mitigate the effect of this change by
> >> surrounding the new ufd field with
> >> #ifdef CONFIG_XENO_DRIVERS_NET_RTIPV4_TCP
> >>
> > 
> > The core layer implementing RTDM fd is not supposed to depend on high
> > level remote features such as tcp protocol over rtnet.
> > 
> > Let's just add the missing info to rtdm_fd unconditionally, we are
> > talking about a few tenths of additional bytes in a typical Xenomai
> > system fitted with several MB of memory (likely less than what would be
> > needed to scan the fd tree to retrieve the same information btw).
> > 
> 
> Ack.
> 

OK, will prepare a patch.

-- 
Sebastian