| 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository |
| From: | Chris Johns via Core-talk <core-talk at aps.anl.gov> |
| To: | joel at rtems.org, Heinz Junkes <junkes at fhi-berlin.mpg.de> |
| Cc: | Core talk <core-talk at aps.anl.gov>, "rtems-devel at rtems.org" <devel at rtems.org> |
| Date: | Fri, 5 Mar 2021 10:09:17 +1100 |
On 5/3/21 1:26 am, Joel Sherrill wrote: > Eventually the NFSv2 client will need to be in the legacy stack > package. But until the port of the FreeBSD NFSv4 client is available > in libbsd, the existing NFSv2 client has to be used for both stacks. The NFSv2 (and RPC?) code can be moved from rtems.git to the net-legacy repo. The libbsd stack contains a separate copy that is built when libbsd is built. I found the NFSv4 port for libbsd cannot coexist in the same build of libbsd as the NFSv2 code. The NFSv4 code is kernel based and has a kernel RPC stack and the NFSv2 code has a user land RPC stack. The FreeBSD user and kernel RPC stacks clashed when I last tried. I will check this again once I have wrapped up the NFSv4 port to see if include magic can help but it is a low priority given NFSv4 has options to specify the NFS version to be used. Chris