Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

#4518 closed defect (fixed)

RTEMS and LibBSD both provide competing pipe() interfaces

Reported by: Chris Johns Owned by: Chris Johns
Priority: normal Milestone: 6.1
Component: network/libbsd Version: 6
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description (last modified by Chris Johns)

RTEMS provides a pipe() call in cpukit/libfs/src/pipe/pipe.c and LibBSD also provides a call in rtemsbsd/rtems/rtems-bsd-syscall-api.c. We should not have competing interfaces.

The selection of the version you get depends on the link order and the linker version. The RTEMS 6 linker seems to have a different preference to RTEMS 5. Apart from this fragility LibBSD should not be providing this interface.

A LibBSD pipe() is problematic for a number of reasons and so I am going to remove the call from it.

If LibBSD support is needed it needs to be via a file system op handles like all other file system interfaces for descriptor based access. I will not be adding this support.

The removal of pipe() from LibBSD removes the kqueue support for pipes. See the test selectpollkqueue01. If this support is needed please contact the RTEMS developers.

Change History (6)

comment:1 Changed on 09/23/21 at 05:32:50 by Chris Johns

Description: modified (diff)

comment:2 Changed on 09/23/21 at 05:34:24 by Chris Johns

Description: modified (diff)

comment:3 Changed on 09/23/21 at 09:16:00 by Chris Johns

Description: modified (diff)

comment:4 Changed on 09/24/21 at 00:03:48 by Chris Johns

Description: modified (diff)
Summary: RTEMS and LibBSD both provide pipe()RTEMS and LibBSD both provide competing pipe() interfaces

comment:5 Changed on 09/24/21 at 00:06:48 by Chris Johns

The removal of pipe() from LibBSD does effect the kqueue support but it also lets the RTEMS version get linked in and do it's work. Pipe for libio descriptors and libmisc/redirector work nicely well before LibBSD is initialised and this is important in some applications. Especially ones that capture the console early to implement a dmesg type of support.

I am happy to see a file op added for pipe however I view RTEMS as having priority over the same call signature in LibBSD if there is a clash and there is.

I have an app that crashes because of this. I have no idea why on RTEMS 5 the RTEMS one is linked in and the same app and build system now results the LibBSD one. Having 2 interfaces is wrong.

comment:6 Changed on 09/24/21 at 00:07:33 by Chris Johns <chrisj@…>

Resolution: fixed
Status: assignedclosed

In [changeset:"2e5f808b09459e5287b39135f06a79f05c1194c9/rtems-libbsd" 2e5f808/rtems-libbsd]:

rtemsbsd/syscalls: Remove pipe()

  • This call is provided by RTEMS and that is preferred

Closes #4518

Note: See TracTickets for help on using tickets.