- Timestamp:
-
08/25/22 20:19:06 (22 months ago)
- Author:
-
Kinsey Moore
- Comment:
-
update and slim down
Legend:
- Unmodified
- Added
- Removed
- Modified
-
v24
|
v25
|
|
32 | 32 | Many POSIX applications expect that sockets and file descriptors are allocated from same space and can be interchanged in many functions (read, write, close etc.) which allows to use fdopen, FILE stream, printf etc. on sockets. Original RTEMS BSD based stack is fully integrated as well as new BSD based stack. There are some pointers and thoughts about this work |
33 | 33 | |
34 | | It is necessary to write bridge between LwIP connections representation and RTEMS file descriptors. Template for this work can be found in |
| 34 | It is necessary to write bridge between LwIP connections representation and RTEMS file descriptors. |
35 | 35 | |
36 | | https://git.rtems.org/rtems/tree/cpukit/libnetworking/rtems/rtems_syscall.c |
| 36 | === Historical Example === |
| 37 | |
| 38 | Template for this work can be found in |
| 39 | |
| 40 | https://git.rtems.org/rtems-net-legacy/tree/rtems/rtems_syscall.c |
37 | 41 | |
38 | 42 | FDs for socket are allocated in function |
… |
… |
|
50 | 54 | |
51 | 55 | which calls function rtems_bsdnet_makeFdForSocket(). That function can be copied unchanged for LwIP bridge. |
| 56 | |
| 57 | === Current Working Method === |
52 | 58 | |
53 | 59 | One option is to map functions to lwip_socket, lwip_recive etc. and keep transformation from RTEMS FD number to LwIP FD number. LwIP FD number can be kept in iop->data1 member type. See function rtems_bsdnet_fdToSocket() in original BSD integrated RTEMS networking. rtems_libio_t structure is defined in |
… |
… |
|
94 | 100 | https://github.com/ppisa/rtems-devel/blob/master/rtems-omk-template/applwiptest/rtems_lwip_io.c |
95 | 101 | |
96 | | Because LwIP sockaddr type can in general differ and AF_XXX and PF_XXX differ |
97 | | between NewLib and LwIP there is implemented layer to translate NewLib application |
98 | | types and defines to from/to LwIP ones |
| 102 | lwIP has its own set of network and socket headers that have been bypassed to use the Newlib headers that RTEMS and LibBSD depend on to provide consistent operation with ported code. |
99 | 103 | |
100 | | https://github.com/ppisa/rtems-devel/blob/master/rtems-omk-template/applwiptest/rtems_lwip_int.h |
101 | | |
102 | | https://github.com/ppisa/rtems-devel/blob/master/rtems-omk-template/applwiptest/rtems_lwip_sysdefs.c |
103 | | |
104 | | This proof of concept solution does not provide select integration and non-block |
105 | | support. But RTEMS provided telnet daemon runs against this implementation. |
| 104 | This solution does not provide non-block support, but RTEMS provided telnet daemon runs against this implementation. |
106 | 105 | Next object files were removed from librtemscpu.a to ensure that LWIP provided ones are used. |
107 | 106 | {{{ |
… |
… |
|
112 | 111 | }}} |
113 | 112 | |
114 | | But simple solution has disadvantage that there are consulted two tables (FD_RTEMS -> RTEMS iop data, FD_LwIP to LwIP connection state) in each operation function. even worse both tables and objects have to be separately allocated and freed. Better solution is to not use LwIP provided FD allocation layer and use directly API working with connection state through structure pointers to struct netconn. LwIP FD API |
115 | | is in the fact based on this lower level API. struct netconn based API implementation can be found in the file |
| 113 | But simple solution has disadvantage that there are consulted two tables (FD_RTEMS -> RTEMS iop data, FD_LwIP to LwIP connection state) in each operation function. even worse both tables and objects have to be separately allocated and freed. Better solution is to not use LwIP provided FD allocation layer and use directly API working with connection state through structure pointers to struct netconn. LwIP FD API is, in fact, based on this lower level API. struct netconn based API implementation can be found in the file |
116 | 114 | |
117 | 115 | http://git.savannah.gnu.org/cgit/lwip.git/tree/src/api/api_lib.c |
118 | 116 | |
119 | | Example, how to use this API can be found in ReactOS operating system LwIP integration which maps LwIP netconn API to Windows handles API |
120 | | |
121 | | https://git.reactos.org/?p=reactos.git;a=blob;f=sdk/lib/drivers/lwip/src/rostcp.c |
122 | | |
123 | | {{{ |
124 | | LibTCPSendCallback(void *arg) |
125 | | }}} |
126 | | {{{ |
127 | | LibTCPSend(PCONNECTION_ENDPOINT Connection, void *const dataptr, const u16_t len, u32_t *sent, const int safe) |
128 | | }}} |
129 | | |
130 | | The other part of ReactOS LwIP integration can be found there |
131 | | |
132 | | https://git.reactos.org/?p=reactos.git;a=blob;f=sdk/lib/drivers/lwip/src/api/tcpip.c |
133 | | |
134 | | {{{ |
135 | | tcpip_callback_with_block(tcpip_callback_fn function, void *ctx, u8_t block) |
136 | | }}} |
137 | | |
138 | | The mapping of the new RTEMS BSD stack to RTEMS CPUkit FD handles can be found in next file as another example |
| 117 | The mapping of the new RTEMS BSD stack to RTEMS CPUkit FD handles can be found in the following file as another example: |
139 | 118 | |
140 | 119 | https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/kern/sys_socket.c |
| 120 | |
| 121 | === Locking === |
141 | 122 | |
142 | 123 | As for the locking, I expect that for beginning there has to be global lock at start of each function pointed by _rtems_filesystem_file_handlers_r operations. It is possible to relax this to per struct netconn separate semaphores later. But for small single CPU targets this would cause higher overhead than global networking lock and for big systems new BSD stack is used anyway. |