Re: Cortex-M floating point (Was: RTEMS 6 branching)
On 2/5/2024 7:18 am, Cedric Berger wrote: > Hello, > > On 25.04.2024 02:16, Chris Johns wrote: >> I know I am getting ahead of myself but once we have GiLab running and you >> have >> a patch you would like merged please make a merge request. > > Done: > > https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/10 > > It worked really well. > Yay and thanks for letting us know. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Cortex-M floating point (Was: RTEMS 6 branching)
Hello, On 25.04.2024 02:16, Chris Johns wrote: I know I am getting ahead of myself but once we have GiLab running and you have a patch you would like merged please make a merge request. Done: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/10 It worked really well. Cedric ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Cortex-M floating point (Was: RTEMS 6 branching)
On 24.04.24 14:37, Cedric Berger wrote: Hello Sebastian, On 23.04.2024 19:56, Sebastian Huber wrote: 1. Are all the things need for the release resolved? Tickets reviewed? It would be nice to have the interrupt get/set priority API in RTEMS 6. The Cortex-M floating point issue is not yet fixed in the RTEMS master. Do you have any feedback on the two patches that I posted on the ticket, which seems to fix the issue? It would be great if you could check the patch at the end of this mail: https://lists.rtems.org/pipermail/devel/2024-February/077228.html -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Cortex-M floating point (Was: RTEMS 6 branching)
On 24/4/2024 10:37 pm, Cedric Berger wrote: > Hello Sebastian, > > On 23.04.2024 19:56, Sebastian Huber wrote: >>> 1. Are all the things need for the release resolved? Tickets reviewed? >> It would be nice to have the interrupt get/set priority API in RTEMS 6. The >> Cortex-M floating point issue is not yet fixed in the RTEMS master. > > Do you have any feedback on the two patches that I posted on the ticket, which > seems to fix the issue? Thanks to everyone for responding. It seems clear the 6 branch will happen once GitLab is launched. Once we launch the 6 milestone can be used with burndown and burnup charts (https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html) to track the branch point. I know I am getting ahead of myself but once we have GiLab running and you have a patch you would like merged please make a merge request. If there is an issue please make sure it is on the 6.1 milestone or create one and assign it to the milestone. In the meantime Amar and I will take a look at the release notes. We think these can be based on a ChangeLog report created via the GitLab API. The wrinkle here is the API needs a key and that of course cannot be exposed in commits. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Cortex-M floating point (Was: RTEMS 6 branching)
On 24/4/2024 10:37 pm, Cedric Berger wrote: > Hello Sebastian, > > On 23.04.2024 19:56, Sebastian Huber wrote: >>> 1. Are all the things need for the release resolved? Tickets reviewed? >> It would be nice to have the interrupt get/set priority API in RTEMS 6. The >> Cortex-M floating point issue is not yet fixed in the RTEMS master. > > Do you have any feedback on the two patches that I posted on the ticket, which > seems to fix the issue? Thanks to everyone for responding. It seems clear the 6 branch will happen once GitLab is launched. Once we launch the 6 milestone can be used with burndown and burnup charts (https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html) to track the branch point. I know I am getting ahead of myself but once we have GiLab running and you have a patch you would like merged please make a merge request. If there is an issue please make sure it is on the 6.1 milestone or create one and assign it to the milestone. In the meantime Amar and I will take a look at the release notes. We think these can be based on a ChangeLog report created via the GitLab API. The wrinkle here is the API needs a key and that of course cannot be exposed in commits. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 6 branching
On 25/4/2024 12:06 am, Peter Dufault wrote: >> On Apr 24, 2024, at 9:27 AM, Kinsey Moore wrote: >> >> That use case definitely wasn't considered for rtems-lwip and I don't know >> that it's ever been discussed. If that were intended, I'd expect a "./waf >> uninstall" target to exist that would remove the installed network stack so >> that you could install a different one since the different stacks install >> vastly different sets of headers. IIRC, Chris advocates for installing the >> network libraries into a different location than the installed BSP to allow >> you to choose which you want at a later time. >> > > I've been moving a driver from legacy to bsd so I definitely need to easily > switch back and forth for the same BSP for testing. > > I agree with Chris, but it's apparently a desirement, not a requirement, so > it shouldn't hold up the branching. Agreed. It would be nice but is it something user would really want or use? I get there are use cases like the one you raise but a single installed network stack in a single install prefix makes it easier to write build system checks to detect the type of stack. I have applications that can switch between legacy and libbsd and that is important when migrating stacks and debugging. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 6 branching
> On Apr 24, 2024, at 9:27 AM, Kinsey Moore wrote: > > That use case definitely wasn't considered for rtems-lwip and I don't know > that it's ever been discussed. If that were intended, I'd expect a "./waf > uninstall" target to exist that would remove the installed network stack so > that you could install a different one since the different stacks install > vastly different sets of headers. IIRC, Chris advocates for installing the > network libraries into a different location than the installed BSP to allow > you to choose which you want at a later time. > > Kinsey I've been moving a driver from legacy to bsd so I definitely need to easily switch back and forth for the same BSP for testing. I agree with Chris, but it's apparently a desirement, not a requirement, so it shouldn't hold up the branching. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 6 branching
On Wed, Apr 24, 2024 at 6:43 AM Peter Dufault wrote: > > On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee > wrote: > > On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill wrote: > > > > > > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > > - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: > > > > > Hi, > > > > > > There has been some discussion about when we will branch and it is > timely we > > > discuss this. This is my input. :) > > > > > > While I create the releases I am not solely responsible for milestone > dates or > > > thresholds for a release. > > > > > > Please test the RC snaphots on our ftp server. Saying you have is as > important > > > as reporting issues. > > > > > > 1. Are all the things need for the release resolved? Tickets reviewed? > > > > It would be nice to have the interrupt get/set priority API in RTEMS 6. > The Cortex-M floating point issue is not yet fixed in the RTEMS master. > > > > There should be time to get it in. The Gitlab transition needs to be > complete before the branch is cut. > > > > > > > > 2. The tickets are now in GitLab and locked down in Trac so how does > that work > > > if we make a release now? I do not think it does. > > > > > > 3. GitLab is going to happen soon so do we take this moment in time > and make 6 > > > with GitLab and learn what we need to do easing dot releases that > always follow? > > > If we do not we may end up with 6.1 and then 6.2 that has differences. > > > > We should definitely wait with the release after the Gitlab migration is > done and some basic CI is running. > > > > I don't think holding a release for CI is needed. We have the same basic > quality and testing we have now. > > > > Requiring more work and improvements just moves the release bar. > > > > That said, we do need to get some CI processes in place. Hopefully > between 6.1 and 6.2, we will have at least one or two BSPs required to > build. > > > > > > > > 4. GitLab breaks the release scripts for the release notes > (ChangeLog). Amar and > > > I have discussed a few options but we are yet to test and settle on > anything. As > > > is the case with these things easy is often is a series of small > things that > > > take time to get right. > > > > > > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are > they updated > > > for a separated legacy network stack, net services and waf building? > > > > Ryan and Ray worked on the autoconf to waf documentation changes a > couple of years ago. > > > > I have no idea what impact the separated Network stacks have on the > documentation. > > > > The legacy networking docs are separated now with instructions on how to > build them using waf: > > https://docs.rtems.org/branches/master/legacy-networking/index.html > > > > We might need to mention in the user manual that there is no default > networking stack anymore and the user needs to build the network stack > separately. > > I do (or did, haven't checked lately) have an issue that if I "./waf > install" one of the network stacks, probably "libbsd", that I can't then > switch back and forth. I think a header file got installed that broke > things. Don't know if that was fixed, I've just been careful to not > install either stack so I can switch. > > Is that a bug? Should I figure out what the problem was and report it? > That use case definitely wasn't considered for rtems-lwip and I don't know that it's ever been discussed. If that were intended, I'd expect a "./waf uninstall" target to exist that would remove the installed network stack so that you could install a different one since the different stacks install vastly different sets of headers. IIRC, Chris advocates for installing the network libraries into a different location than the installed BSP to allow you to choose which you want at a later time. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Cortex-M floating point (Was: RTEMS 6 branching)
Hello Sebastian, On 23.04.2024 19:56, Sebastian Huber wrote: 1. Are all the things need for the release resolved? Tickets reviewed? It would be nice to have the interrupt get/set priority API in RTEMS 6. The Cortex-M floating point issue is not yet fixed in the RTEMS master. Do you have any feedback on the two patches that I posted on the ticket, which seems to fix the issue? Thanks, Cedric ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 6 branching
> On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee wrote: > > > > On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill wrote: > > > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber > wrote: > - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: > > > Hi, > > > > There has been some discussion about when we will branch and it is timely we > > discuss this. This is my input. :) > > > > While I create the releases I am not solely responsible for milestone dates > > or > > thresholds for a release. > > > > Please test the RC snaphots on our ftp server. Saying you have is as > > important > > as reporting issues. > > > > 1. Are all the things need for the release resolved? Tickets reviewed? > > It would be nice to have the interrupt get/set priority API in RTEMS 6. The > Cortex-M floating point issue is not yet fixed in the RTEMS master. > > There should be time to get it in. The Gitlab transition needs to be complete > before the branch is cut. > > > > > 2. The tickets are now in GitLab and locked down in Trac so how does that > > work > > if we make a release now? I do not think it does. > > > > 3. GitLab is going to happen soon so do we take this moment in time and > > make 6 > > with GitLab and learn what we need to do easing dot releases that always > > follow? > > If we do not we may end up with 6.1 and then 6.2 that has differences. > > We should definitely wait with the release after the Gitlab migration is done > and some basic CI is running. > > I don't think holding a release for CI is needed. We have the same basic > quality and testing we have now. > > Requiring more work and improvements just moves the release bar. > > That said, we do need to get some CI processes in place. Hopefully between > 6.1 and 6.2, we will have at least one or two BSPs required to build. > > > > > 4. GitLab breaks the release scripts for the release notes (ChangeLog). > > Amar and > > I have discussed a few options but we are yet to test and settle on > > anything. As > > is the case with these things easy is often is a series of small things that > > take time to get right. > > > > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they > > updated > > for a separated legacy network stack, net services and waf building? > > Ryan and Ray worked on the autoconf to waf documentation changes a couple of > years ago. > > I have no idea what impact the separated Network stacks have on the > documentation. > > The legacy networking docs are separated now with instructions on how to > build them using waf: > https://docs.rtems.org/branches/master/legacy-networking/index.html > > We might need to mention in the user manual that there is no default > networking stack anymore and the user needs to build the network stack > separately. I do (or did, haven't checked lately) have an issue that if I "./waf install" one of the network stacks, probably "libbsd", that I can't then switch back and forth. I think a header file got installed that broke things. Don't know if that was fixed, I've just been careful to not install either stack so I can switch. Is that a bug? Should I figure out what the problem was and report it? > > > 6. I have a few small patches to push and then an update to the RSB to pick > > those changes up before I can create RC4. > > I recently checked in a fix for powerpc and the AArch64 multilib changes for > Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be updated. > Maybe we should even wait for the GCC 13.3 release. > > I asked about a gcc 13.3 release and we should not wait. They intend to do a > 14 release before returning to 13.3. We should plan to do 6.1 with a GCC 13 > branch hash and probably plan to swap that out with a 13.3 tarball when it's > released. > > We are good at imposing more requirements. :) > > Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 6 branching
On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill wrote: > > > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: >> >> > Hi, >> > >> > There has been some discussion about when we will branch and it is >> timely we >> > discuss this. This is my input. :) >> > >> > While I create the releases I am not solely responsible for milestone >> dates or >> > thresholds for a release. >> > >> > Please test the RC snaphots on our ftp server. Saying you have is as >> important >> > as reporting issues. >> > >> > 1. Are all the things need for the release resolved? Tickets reviewed? >> >> It would be nice to have the interrupt get/set priority API in RTEMS 6. >> The Cortex-M floating point issue is not yet fixed in the RTEMS master. >> > > There should be time to get it in. The Gitlab transition needs to be > complete before the branch is cut. > >> >> > >> > 2. The tickets are now in GitLab and locked down in Trac so how does >> that work >> > if we make a release now? I do not think it does. >> > >> > 3. GitLab is going to happen soon so do we take this moment in time and >> make 6 >> > with GitLab and learn what we need to do easing dot releases that >> always follow? >> > If we do not we may end up with 6.1 and then 6.2 that has differences. >> >> We should definitely wait with the release after the Gitlab migration is >> done and some basic CI is running. >> > > I don't think holding a release for CI is needed. We have the same basic > quality and testing we have now. > > Requiring more work and improvements just moves the release bar. > > That said, we do need to get some CI processes in place. Hopefully between > 6.1 and 6.2, we will have at least one or two BSPs required to build. > >> >> > >> > 4. GitLab breaks the release scripts for the release notes (ChangeLog). >> Amar and >> > I have discussed a few options but we are yet to test and settle on >> anything. As >> > is the case with these things easy is often is a series of small things >> that >> > take time to get right. >> > >> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they >> updated >> > for a separated legacy network stack, net services and waf building? >> > > Ryan and Ray worked on the autoconf to waf documentation changes a couple > of years ago. > > I have no idea what impact the separated Network stacks have on the > documentation. > The legacy networking docs are separated now with instructions on how to build them using waf: https://docs.rtems.org/branches/master/legacy-networking/index.html We might need to mention in the user manual that there is no default networking stack anymore and the user needs to build the network stack separately. > > > 6. I have a few small patches to push and then an update to the RSB to >> pick >> > those changes up before I can create RC4. >> >> I recently checked in a fix for powerpc and the AArch64 multilib changes >> for Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be >> updated. Maybe we should even wait for the GCC 13.3 release. >> > > I asked about a gcc 13.3 release and we should not wait. They intend to do > a 14 release before returning to 13.3. We should plan to do 6.1 with a GCC > 13 branch hash and probably plan to swap that out with a 13.3 tarball when > it's released. > > We are good at imposing more requirements. :) > > > > >> > >> > >> > Thanks >> > Chris >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> >> -- >> embedded brains GmbH & Co. KG >> Herr Sebastian HUBER >> Dornierstr. 4 >> 82178 Puchheim >> Germany >> email: sebastian.hu...@embedded-brains.de >> phone: +49-89-18 94 741 - 16 >> fax: +49-89-18 94 741 - 08 >> >> Registergericht: Amtsgericht München >> Registernummer: HRB 157899 >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >> Unsere Datenschutzerklärung finden Sie hier: >> https://embedded-brains.de/datenschutzerklaerung/ >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 6 branching
On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: > > > Hi, > > > > There has been some discussion about when we will branch and it is > timely we > > discuss this. This is my input. :) > > > > While I create the releases I am not solely responsible for milestone > dates or > > thresholds for a release. > > > > Please test the RC snaphots on our ftp server. Saying you have is as > important > > as reporting issues. > > > > 1. Are all the things need for the release resolved? Tickets reviewed? > > It would be nice to have the interrupt get/set priority API in RTEMS 6. > The Cortex-M floating point issue is not yet fixed in the RTEMS master. > There should be time to get it in. The Gitlab transition needs to be complete before the branch is cut. > > > > > 2. The tickets are now in GitLab and locked down in Trac so how does > that work > > if we make a release now? I do not think it does. > > > > 3. GitLab is going to happen soon so do we take this moment in time and > make 6 > > with GitLab and learn what we need to do easing dot releases that always > follow? > > If we do not we may end up with 6.1 and then 6.2 that has differences. > > We should definitely wait with the release after the Gitlab migration is > done and some basic CI is running. > I don't think holding a release for CI is needed. We have the same basic quality and testing we have now. Requiring more work and improvements just moves the release bar. That said, we do need to get some CI processes in place. Hopefully between 6.1 and 6.2, we will have at least one or two BSPs required to build. > > > > > 4. GitLab breaks the release scripts for the release notes (ChangeLog). > Amar and > > I have discussed a few options but we are yet to test and settle on > anything. As > > is the case with these things easy is often is a series of small things > that > > take time to get right. > > > > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they > updated > > for a separated legacy network stack, net services and waf building? > Ryan and Ray worked on the autoconf to waf documentation changes a couple of years ago. I have no idea what impact the separated Network stacks have on the documentation. > 6. I have a few small patches to push and then an update to the RSB to > pick > > those changes up before I can create RC4. > > I recently checked in a fix for powerpc and the AArch64 multilib changes > for Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be > updated. Maybe we should even wait for the GCC 13.3 release. > I asked about a gcc 13.3 release and we should not wait. They intend to do a 14 release before returning to 13.3. We should plan to do 6.1 with a GCC 13 branch hash and probably plan to swap that out with a 13.3 tarball when it's released. We are good at imposing more requirements. :) > > > > > > Thanks > > Chris > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > -- > embedded brains GmbH & Co. KG > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 6 branching
- Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: > Hi, > > There has been some discussion about when we will branch and it is timely we > discuss this. This is my input. :) > > While I create the releases I am not solely responsible for milestone dates or > thresholds for a release. > > Please test the RC snaphots on our ftp server. Saying you have is as important > as reporting issues. > > 1. Are all the things need for the release resolved? Tickets reviewed? It would be nice to have the interrupt get/set priority API in RTEMS 6. The Cortex-M floating point issue is not yet fixed in the RTEMS master. > > 2. The tickets are now in GitLab and locked down in Trac so how does that work > if we make a release now? I do not think it does. > > 3. GitLab is going to happen soon so do we take this moment in time and make 6 > with GitLab and learn what we need to do easing dot releases that always > follow? > If we do not we may end up with 6.1 and then 6.2 that has differences. We should definitely wait with the release after the Gitlab migration is done and some basic CI is running. > > 4. GitLab breaks the release scripts for the release notes (ChangeLog). Amar > and > I have discussed a few options but we are yet to test and settle on anything. > As > is the case with these things easy is often is a series of small things that > take time to get right. > > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they > updated > for a separated legacy network stack, net services and waf building? > > 6. I have a few small patches to push and then an update to the RSB to pick > those changes up before I can create RC4. I recently checked in a fix for powerpc and the AArch64 multilib changes for Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be updated. Maybe we should even wait for the GCC 13.3 release. > > > Thanks > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS 6 branching
Hi, There has been some discussion about when we will branch and it is timely we discuss this. This is my input. :) While I create the releases I am not solely responsible for milestone dates or thresholds for a release. Please test the RC snaphots on our ftp server. Saying you have is as important as reporting issues. 1. Are all the things need for the release resolved? Tickets reviewed? 2. The tickets are now in GitLab and locked down in Trac so how does that work if we make a release now? I do not think it does. 3. GitLab is going to happen soon so do we take this moment in time and make 6 with GitLab and learn what we need to do easing dot releases that always follow? If we do not we may end up with 6.1 and then 6.2 that has differences. 4. GitLab breaks the release scripts for the release notes (ChangeLog). Amar and I have discussed a few options but we are yet to test and settle on anything. As is the case with these things easy is often is a series of small things that take time to get right. 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they updated for a separated legacy network stack, net services and waf building? 6. I have a few small patches to push and then an update to the RSB to pick those changes up before I can create RC4. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
