Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
Hi Simon, I did find the RTOS SDK, but I'm an old bare-metal die-hard. I need to keep the AT commands too, and that seems to be supported on the non-OS SDK (but I didn't dive too deep). I also found some guys that have run some diffs and created some patches, and then provide a newer stack. That is a "cheaper" alternative. This beast has little RAM and no ROM, it pulls code out of an SPI flash to RAM or to an execution cache. Those fancy attributes are to put functions on the execution cache, freeing valuable RAM for heavy use stuff. What worries me are those os_ prefixed functions, the chip has been crafted to work as a wifi machine and basically other use is robbing processor to its main function, so fooling around with something not provided by the manufacturer can easily turn to a nightmare. Not that what they provide can't... but seems to be somewhat more "tested". I think I'll stay with the stock stack until there is a real need for production-quality code (and someone to be charged for its generation). Thanks for your comments!!! ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
Sergio R. Caprile wrote: > Oh, the vendor had put that into ip_addr.h > Heavily modified... even more than I thought. Did you check the RTOS SDK? It seems the lwIP version included there is much more recent (although quite old, they're still using ipX_addr_t) and not as heavily modified. Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
Sergio R. Caprile wrote: >>> 1.4.0 -> 1.4.1 required the addition of the ip_info structure, which had >> That's not an lwIP structure: I've never heard of that name. > Oh, the vendor had put that into ip_addr.h > Heavily modified... even more than I thought. Right. Now that I found the sources they provide, I'm not sure what you're trying to do is a good idea, unless you have plenty of time :-) On the other hand, you could properly fix their port to use "vanilla" lwIP plus the appropriate porting mechanisms and send it back to them? ;-) BTW: I didn't quite get if all those attributes to functions/variables are really required or if it's just a kind of optimization that is rather optional... Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
1.4.0 -> 1.4.1 required the addition of the ip_info structure, which had That's not an lwIP structure: I've never heard of that name. Oh, the vendor had put that into ip_addr.h Heavily modified... even more than I thought. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
Sergio R. Caprile wrote: > 1.4.0 -> 1.4.1 required the addition of the ip_info structure, which had > been deprecated. That's not an lwIP structure: I've never heard of that name. > [..] My journey stopped here, as at that point I discovered these people had > highly modified the lwIP stack for their needs, having many private > memory related functions, making my adventure quite unpleasant and > unportable. ... and that's the downside of having a BSD license, not LGPL ;-) Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
1.4.0 -> 1.4.1 required the addition of the ip_info structure, which had been deprecated. I could do that on user files, the module manufacturer used that structure for internal stuff. Everything compiled straightforward once I copied the sys_now() from their version of sys.h... My journey stopped here, as at that point I discovered these people had highly modified the lwIP stack for their needs, having many private memory related functions, making my adventure quite unpleasant and unportable. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
Thank you very much guys, probably next weeks I'll give 1.4.0 -> 1.4.1 a try, spare time permitting. Will keep you posted. Next attempt will probably be 1.4.1 -> 2.0.0, at least a compile test to list the ABI issues to be resolved for case evaluation. It's going to be IPv4-only for now. Next will be my Ethernet driver update and adecuation for use with IPv6, but I think I'll probably open another thread for that in due time. This is "play-along" and time is scarce. Best regards ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
Hi Simon, On Mon, Aug 08, 2016 at 10:17:15PM +0200, goldsi...@gmx.de wrote: > Sylvain Rochet wrote: > >Humm, I would have thought that a revision release didn't change the API > >at all, > > Thinking about it again, I guess it was an ABI change, not an API change. > For the target of lwIP (at that time?) keeping the API stable was enough. Well, that was the question :-), whether we should go to API or ABI stable, from my point of view, keeping the API stable is well enough. > And remember the API does *not* include struct layout (not event struct > members, since users should access the structs via defines, not the > members). Indeed. > I don't think that changes with 2.0.0 unless there are strong request > to keep the ABI stable. I'm not willing too, either. Keeping the API stable only require contrib examples to build and work without change, keeping the ABI stable require a check that exported symbols didn't change at all. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
Sylvain Rochet wrote: Humm, I would have thought that a revision release didn't change the API at all, Thinking about it again, I guess it was an ABI change, not an API change. For the target of lwIP (at that time?) keeping the API stable was enough. And remember the API does *not* include struct layout (not event struct members, since users should access the structs via defines, not the members). I don't think that changes with 2.0.0 unless there are strong request to keep the ABI stable. Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
Hi, On Mon, Aug 08, 2016 at 08:17:42PM +0200, goldsi...@gmx.de wrote: > > Right. We didn't have binary compatiblity in mind, so after removing some > flags, some other flags' values have changed. That might still work if you > fix them up after netif_add() (which calls the netif's init function)... We can't really have binary, nor source compatibility between lwIP releases, thinking a bit about it, woah, it sounds like this is close to impossible to achieve by keeping the code small and readable And that's was releases are for anyway, except last digit release, the other 2 digits actually share the same meaning about API/ABI break. > Fixing up the lwIP import symbols in the driver library might be nicer > than changing the lwIP sources (or else some other lwIP things might > stop working), but I haven't done this, yet, and it might largely > depend on the compiler used. I didn't thought of that but renaming symbols names in the blob to use the shim layer instead should work, indeed ;) This is what I would do in this situation, after thinking about it again. > Regarding 1.4.0 --> 1.4.1, the only API change was in TCP, I think (minor > API change, struct tcp_pcb layout change). That shouldn't make a difference > for you, so 1.4.1 should be an easy replacement. Humm, I would have thought that a revision release didn't change the API at all, we should prevent that to happen for 2.0.x by forbidding API change (ABI?) for revision releases. So all 2.0.x further releases should be API(ABI?) compatible with 2.0.0, any API(ABI?) change should go to 2.1.0. What do you think ? Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
Sylvain Rochet wrote: Humm, the raw API didn't change much, so it should be fine. I guess so, too. In any way, if you have the sources, you could even fix it if it needs fixing. I hope it doesn't (unless you add IPv6, in that case, it might). However, the netif API changed… especially if you want IPv6. If you stick to IPv4 you will probably trip over the administrative state and link state rework You can just set the netif's link up after adding, so that should work. as well as some other flags, Right. We didn't have binary compatiblity in mind, so after removing some flags, some other flags' values have changed. That might still work if you fix them up after netif_add() (which calls the netif's init function)... the netif struct changed as well IIRC so it's not ABI compatible at all. Unless LWIP_SNMP was enabled for 1.4.0, struct netif should have the same layout. But that largely depends on the enabled options in opt.h/lwipopts.h... :-( But what you could do is to rename all netif calls and netif struct in lwIP and write a shim layer between the symbols used in your blob and the renamed lwIP calls. Fixing up the lwIP import symbols in the driver library might be nicer than changing the lwIP sources (or else some other lwIP things might stop working), but I haven't done this, yet, and it might largely depend on the compiler used. Regarding 1.4.0 --> 1.4.1, the only API change was in TCP, I think (minor API change, struct tcp_pcb layout change). That shouldn't make a difference for you, so 1.4.1 should be an easy replacement. Please keep us informed and cry for help if you run into problems as this is very interesting (to me at least:) Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] 1.4.0 -> 1.4.1 or 2.0.0
Hi Sergio, On Mon, Aug 08, 2016 at 02:23:13PM -0300, Sergio R. Caprile wrote: > Hi there, > here I am with this chinese module having linkable libraries for the link > layer driver (no source) and an (I think) netconn-like layer over RAW API > (yes source), developed for lwIP 1.4.0RC2. Introducing ESP8266. > Let's say I want to move to 1.4.1 or even 2.0.0 > For 2.0.0, I think that (at least) I'll have to provide a stub so it can > link the calls to tcp_accepted(). > Starting my migration with 1.4.1, any look ahead on my possible nightmares ? > Desired target is 2.0.0 of course, but law of minimum effort still applies. > I haven't been brave enough to even try compiling, I will if your responses > are encouraging or I find myself bored enough and there's no beer. > Cheers. Humm, the raw API didn't change much, so it should be fine. However, the netif API changed… especially if you want IPv6. If you stick to IPv4 you will probably trip over the administrative state and link state rework as well as some other flags, the netif struct changed as well IIRC so it's not ABI compatible at all. But what you could do is to rename all netif calls and netif struct in lwIP and write a shim layer between the symbols used in your blob and the renamed lwIP calls. Good luck, by the way :-) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
