On Mon, Feb 1, 2021 at 4:54 PM Mr. Andrei Chichak <gro...@chichak.ca> wrote:
> Oh, crap, I’m off by 3 orders of magnitude, I’ve got 512KB. > That's an LWIP candidate. :) But Sebastian did a driver for libbsd for the H7 series. If you have more memory or can attach external RAM, that's an option. > Bother, I need a nap already. > > A > > On 2021-February-01, at 15:35, Joel Sherrill <j...@rtems.org> wrote: > > > > On Mon, Feb 1, 2021 at 4:25 PM Andrei Chichak <and...@chichak.ca> wrote: > >> any guidance choosing between “Legacy Stack” and libbsd? >> > > This one is easy. Please please please please do NOT choose the legacy > stack. :) > > The legacy stack should only be used on projects that are using it and > those > are encouraged to move along to libbsd or lwip or new hardware. We have no > plans to eliminate the legacy stack from the world. But as Gedare said, we > want > to move it to a separate repository. If someone cares, then it gets a > build system > and can be used with a strong discouragement. > > It is 20+ years old now and IPV4 only. Do the math. :) > > >> >> I’ve got a 512MB of RAM processor, so I expect that I’ll have lots left >> over. But that is TBD. >> > > 512MB is still huge in RTEMS terms. That won't be a problem for libbsd at > all. It is when you > start considering targets with < 16MB that we have concerns. I suspect > that number is <4MB > but the original BSP for the legacy stack only had 1MB for code and data > space. It is clear > some boards that could run the legacy stack will not be capable of running > libbsd but we > don't have a hard cutoff yet. > > --joel > >> >> A >> >> On 2021-February-01, at 15:21, Joel Sherrill <j...@rtems.org> wrote: >> >> >> >> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom <ged...@rtems.org> wrote: >> >>> >>> >>> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns <chr...@rtems.org> wrote: >>> >>>> On 2/2/21 8:32 am, Mr. Andrei Chichak wrote: >>>> > Is there any advantage to using bsd networking over LWiP, or vice >>>> versa? >>>> >>>> They are different stacks with different feature sets and different >>>> hardware >>>> resource demands. I am not familiar with the features of LwIP so I am >>>> not the >>>> best person to compare them. >>>> >>>> The BSD stack has most of the features you get with FreeBSD. It has >>>> IPv4, IPv6, >>>> IPsec, VLAN, bridging, dhcp, openssl, lots of routing alternatives, >>>> packet >>>> filtering and more. It has a range of useful commands including tcpdump. >>>> >>>> The BSD based system provides a solid base to solve a range of >>>> networking issues >>>> your RTEMS device may encounter at the system level and not at the low >>>> level >>>> programming level. >>>> >>>> The BSD stack uses a lot more resources to do all this and LwIP may be >>>> a prefect >>>> fit. I welcome RTEMS being able to support a range of networking >>>> solutions. >>>> >>>> >>> I have a student (Vijay) working on refactoring libnetworking out of >>> RTEMS, and will be testing ability to compile legacy vs libbsd. If the lwip >>> build is demonstrated and clear, I can have him also look at bringing that >>> into the fold. This is in line with https://devel.rtems.org/ticket/3850 >>> >> >> One thing to be aware of is that all the POSIX networking header files >> for RTEMS are in newlib and always present. I had to address this and lwip >> when we did Deos+RTEMS. Deos uses lwip as their native stack running in a >> partition and other partitions use a client to get to it. The lwip >> constants had values that were not the same as the RTEMS BSD headers for >> POSIX defines. There were also some places where the structure definitions >> did not align. I had to write a bit of mapping in the client. When lwip >> works at all, it would be awesome to have a way for it to ignore their own >> minimal POSIX API files and build against ours. >> >> This would be similar to how the newlib headers define a very complete >> POSIX API set but each target OS may only support a subset of it. >> >> As it is, I wonder if there is a conflict between the RTEMS newlib >> network .h files and those provided by lwip which could cause issues. >> >> >>> >>> We have no certain timeline yet, but it is now work-in-progress. We will >>> bring to devel when progress is made. If we do lwIP too, we will aim to do >>> a performance analysis with real hardware, so that we can hopefully provide >>> evidence to help these kind of questions. >>> >>> -Gedare >>> >>> Chris >>>> >>> _______________________________________________ >>> users mailing list >>> users@rtems.org >>> http://lists.rtems.org/mailman/listinfo/users >> >> _______________________________________________ >> users mailing list >> users@rtems.org >> http://lists.rtems.org/mailman/listinfo/users >> >> >> --------------------- >> Andrei Chichak >> 4024-120 STREET >> EDMONTON, ALBERTA >> T6J 1X8 >> CANADA >> >> >> Phone: 780-434-6266 >> Skype: andrei.chichak >> >> >> >> >> >> >> _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users > > > > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users