Michael, You absolutely don't need to worry. Those are only ideas and if that change really should come, netconn API will either stay or be replaced by nearly equal API calls which would be easy to replace...
Cheers, Simon Am 29. Jan. 2017, 12:34, um 12:34, Michael Steinberg <[email protected]> schrieb: >Hi guys, > >for my private work with lwip I ended up using NO_SYS=1 and rolling my >own thread and api based upon the low level interfaces. But now I'm in >a >situation where I have to use the tcpip thread and am left with either >the socket api or the netconn api. In my personal opinion, the bsd >socket api does not really blend well into the embedded environment, at > >least if you're running the system on OS's where not everything is >considered a file. I'm constantly in a situation where I can't >synchronize accesses to the socket, since the select call only knows >the >lwip part of the world. So my natural course of action is to using the >netconn api, which gives the opportunity to do manual synchronization >with other parts of the target software and flexible sleeping due to >the >callbacks it provides. > >But on the other hand I read about people's opinions that netconn >should >be deprecated or rather be considered an implementation detail, which I > >cannot really understand due to the reasons given above. My question >is, >will the api stay stable, or at least stay "there", even if it evolves? > >I have the feeling that I might spend my time using a sinking ship. >Also >I want to express my vote to "please keep an event based/callback based > >api" with this. > >Regards, >Michael > > >_______________________________________________ >lwip-users mailing list >[email protected] >https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
