Changes between Version 24 and Version 25 of Packages/LWIP


Ignore:
Timestamp:
08/25/22 20:19:06 (20 months ago)
Author:
Kinsey Moore
Comment:

update and slim down

Legend:

Unmodified
Added
Removed
Modified

  • Packages/LWIP

    v24 v25  
    3232Many 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
    3333
    34 It is necessary to write bridge between LwIP connections representation and RTEMS file descriptors. Template for this work can be found in
     34It is necessary to write bridge between LwIP connections representation and RTEMS file descriptors.
    3535
    36 https://git.rtems.org/rtems/tree/cpukit/libnetworking/rtems/rtems_syscall.c
     36=== Historical Example ===
     37
     38Template for this work can be found in
     39
     40https://git.rtems.org/rtems-net-legacy/tree/rtems/rtems_syscall.c
    3741
    3842FDs for socket are allocated in function
    … …  
    5054
    5155which calls function rtems_bsdnet_makeFdForSocket(). That function can be copied unchanged for LwIP bridge.
     56
     57=== Current Working Method ===
    5258
    5359One 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
    … …  
    94100https://github.com/ppisa/rtems-devel/blob/master/rtems-omk-template/applwiptest/rtems_lwip_io.c
    95101
    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
     102lwIP 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.
    99103
    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.
     104This solution does not provide non-block support, but RTEMS provided telnet daemon runs against this implementation.
    106105Next object files were removed from librtemscpu.a to ensure that LWIP provided ones are used.
    107106{{{
    … …  
    112111}}}
    113112
    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
     113But 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
    116114
    117115http://git.savannah.gnu.org/cgit/lwip.git/tree/src/api/api_lib.c
    118116
    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
     117The mapping of the new RTEMS BSD stack to RTEMS CPUkit FD handles can be found in the following file as another example:
    139118
    140119https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/kern/sys_socket.c
     120
     121=== Locking ===
    141122
    142123As 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.