You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by "Alan C. Assis" <ac...@gmail.com> on 2024/07/04 21:21:12 UTC
[OT] Moving to a RTOS on the RP2040
Nice post for a guy (apparently with previous Linux experience, that type
of person normally find their way well on NuttX) moving from baremetal to
RTOS:
https://blog.brixit.nl/moving-to-a-rtos-on-the-rp2040/
The issue he commented about "make distclean" not working is serious and we
need to find a solution to work transparently. Instead of cloning nuttx and
apps again and again as he just did, I just remove the .config and run
./tools/configure.sh again without problem.
But obviously it is not the ideal solution, we need to find a way to keep
apps and nuttx in sync or at least no mess with our users.
BR,
Alan
Re: [OT] Moving to a RTOS on the RP2040
Posted by "Alan C. Assis" <ac...@gmail.com>.
Thank you Greg!
I didn't know about this detail, normally I use only "depends on" and
"select", but in fact "default" fixes the issue!
I will submit some fixes to improve our Kconfig. I invite other to help:
whenever you see some unsatisfied dependence, please submit a fix.
BR,
Alan
On Sun, Jul 7, 2024 at 9:19 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> On 7/7/2024 6:05 AM, Alan C. Assis wrote:
> > I was thinking about an idea to include some #ifdefs to detect that some
> > probable feature combination:
> >
> > https://github.com/apache/nuttx/pull/12638
> >
> > I.E.: if the user selected NET and IPv4 it is probable that he will
> need
> > ICMP, but we cannot enforce this rule on Kconfig because someone could
> want
> > to use his device without ICMP.
> >
> > But that solution will end up bringing more #ifdef to the code that is
> > something we don't want and we should avoid.
>
> Can you can accomplish this in the Kconfig be using a default value that
> depends on IPv4 like:
>
> config NET_ICMP
> ....
> default NET_IPv4
>
> You can still disable ICMP, but the default should be "enabled" if IPv4
> is enabled.
>
>
Re: [OT] Moving to a RTOS on the RP2040
Posted by Gregory Nutt <sp...@gmail.com>.
On 7/7/2024 6:05 AM, Alan C. Assis wrote:
> I was thinking about an idea to include some #ifdefs to detect that some
> probable feature combination:
>
> https://github.com/apache/nuttx/pull/12638
>
> I.E.: if the user selected NET and IPv4 it is probable that he will need
> ICMP, but we cannot enforce this rule on Kconfig because someone could want
> to use his device without ICMP.
>
> But that solution will end up bringing more #ifdef to the code that is
> something we don't want and we should avoid.
Can you can accomplish this in the Kconfig be using a default value that
depends on IPv4 like:
config NET_ICMP
....
default NET_IPv4
You can still disable ICMP, but the default should be "enabled" if IPv4
is enabled.
Re: [OT] Moving to a RTOS on the RP2040
Posted by "Alan C. Assis" <ac...@gmail.com>.
I investigated the issue and in fact it was caused by a logic error in our
netinit.c, I just submitted a fix:
https://github.com/apache/nuttx-apps/pull/2435/commits/0ee93e1aaaca9de2680458278253eeed85808ac
<https://github.com/apache/nuttx-apps/pull/2435/commits/0ee93e1aaaca9de2680458278253eeed85808ac1>
I was thinking about an idea to include some #ifdefs to detect that some
probable feature combination:
https://github.com/apache/nuttx/pull/12638
I.E.: if the user selected NET and IPv4 it is probable that he will need
ICMP, but we cannot enforce this rule on Kconfig because someone could want
to use his device without ICMP.
But that solution will end up bringing more #ifdef to the code that is
something we don't want and we should avoid.
Xiang Xiao pointed a nice presentation from RedHat guy about it and how the
solved similar issue:
https://people.netfilter.org/hawk/presentations/ifdef2016/ifdef_FOSD2016.pdf
I believe this is the way to go! Let's do it!
BR,
Alan
On Fri, Jul 5, 2024 at 11:43 AM Alan C. Assis <ac...@gmail.com> wrote:
> Nathan,
> Absolutely!
>
> I'm talking with him and he already spotted many issues.
> Other issues we all faced and we didn't care, like enabling DHCPC and the
> Kconfig didn't enable DNSCLIENT).
> Although we know that in theory people could use DHCPC without DNS, in
> common usage it will not happen.
>
> He also pointed out something we never thought was an issue: he enabled
> DHCPC and didn't get the dhcpclient command in the shell.
> Why are we using "renew" name? It is not used on Linux or BSD! Maybe we
> should rename it to something that end users will recognize easily from
> Linux.
>
> I think it is important to listen to our users, this feedback is very
> useful to help us to improve our system.
>
> Best Regards,
>
> Alan
>
>
> On Thu, Jul 4, 2024 at 11:51 PM Nathan Hartman <ha...@gmail.com>
> wrote:
>
>> On Thu, Jul 4, 2024 at 7:19 PM Gregory Nutt <sp...@gmail.com> wrote:
>>
>> >
>> > On 7/4/2024 4:44 PM, Alan C. Assis wrote:
>> > > I think Greg avoided using submodules because there are many issues
>> > caused
>> > > by it.
>> > >
>> > > In fact submodules could avoid this issue, but maybe we could have
>> some
>> > > marks indicating the last commit expected on apps/ to the current
>> nuttx/
>> > >
>> > > This way if someone git pull the nuttx/ and forgot to git pull the
>> apps/
>> > > the make will detect it and will ask the user to do it.
>> > >
>> > > I don't like this approach because it makes things more rigid
>> > (inflexible).
>> > > This is not something easy to fix.
>> > >
>> > > BR,
>> > >
>> > > Alan
>> >
>> > That coupling could cause problems with the separation of OS and
>> > applications. We've done a lot of effort to assure that the apps are
>> > totally independent of the OS and totally optional.
>> >
>> > In the past, apps, Documentation, boards, and arch were all submodules.
>> > Users hated the use of submodules and I would be hesitant to ever force
>> > that on users again. It really complicates and slows down progress when
>> > you don't know if a change is in the currently selected submodule or
>> > not. It basically requires a PR and merge or more per day to be usable.
>> >
>> >
>> >
>> > It sounds like submodules are a bad idea... ok, scratch that idea.
>>
>> In the blog he said he didn't want a shell & etc so it sounds like he
>> doesn't know that he can have his own apps repo, or use our apps repo but
>> disable NSH and use his own program as the initial task. Also since he had
>> trouble with debugging on FreeRTOS we should point out that the NSH shell
>> and various builtins (if you enable these features) can be very useful for
>> interactively debugging your board.
>>
>> All in all a good blog post and I think good feedback for us. We should
>> improve distclean (maybe force it to actually distclean no matter what the
>> current state is on disk) and we should improve documentation, especially
>> to teach what kinds of things you can interactively test with a shell, and
>> then disable the shell when no longer needed.
>>
>> Cheers,
>> Nathan
>>
>
Re: [OT] Moving to a RTOS on the RP2040
Posted by "Alan C. Assis" <ac...@gmail.com>.
Nathan,
Absolutely!
I'm talking with him and he already spotted many issues.
Other issues we all faced and we didn't care, like enabling DHCPC and the
Kconfig didn't enable DNSCLIENT).
Although we know that in theory people could use DHCPC without DNS, in
common usage it will not happen.
He also pointed out something we never thought was an issue: he enabled
DHCPC and didn't get the dhcpclient command in the shell.
Why are we using "renew" name? It is not used on Linux or BSD! Maybe we
should rename it to something that end users will recognize easily from
Linux.
I think it is important to listen to our users, this feedback is very
useful to help us to improve our system.
Best Regards,
Alan
On Thu, Jul 4, 2024 at 11:51 PM Nathan Hartman <ha...@gmail.com>
wrote:
> On Thu, Jul 4, 2024 at 7:19 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> >
> > On 7/4/2024 4:44 PM, Alan C. Assis wrote:
> > > I think Greg avoided using submodules because there are many issues
> > caused
> > > by it.
> > >
> > > In fact submodules could avoid this issue, but maybe we could have some
> > > marks indicating the last commit expected on apps/ to the current
> nuttx/
> > >
> > > This way if someone git pull the nuttx/ and forgot to git pull the
> apps/
> > > the make will detect it and will ask the user to do it.
> > >
> > > I don't like this approach because it makes things more rigid
> > (inflexible).
> > > This is not something easy to fix.
> > >
> > > BR,
> > >
> > > Alan
> >
> > That coupling could cause problems with the separation of OS and
> > applications. We've done a lot of effort to assure that the apps are
> > totally independent of the OS and totally optional.
> >
> > In the past, apps, Documentation, boards, and arch were all submodules.
> > Users hated the use of submodules and I would be hesitant to ever force
> > that on users again. It really complicates and slows down progress when
> > you don't know if a change is in the currently selected submodule or
> > not. It basically requires a PR and merge or more per day to be usable.
> >
> >
> >
> > It sounds like submodules are a bad idea... ok, scratch that idea.
>
> In the blog he said he didn't want a shell & etc so it sounds like he
> doesn't know that he can have his own apps repo, or use our apps repo but
> disable NSH and use his own program as the initial task. Also since he had
> trouble with debugging on FreeRTOS we should point out that the NSH shell
> and various builtins (if you enable these features) can be very useful for
> interactively debugging your board.
>
> All in all a good blog post and I think good feedback for us. We should
> improve distclean (maybe force it to actually distclean no matter what the
> current state is on disk) and we should improve documentation, especially
> to teach what kinds of things you can interactively test with a shell, and
> then disable the shell when no longer needed.
>
> Cheers,
> Nathan
>
Re: [OT] Moving to a RTOS on the RP2040
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Jul 4, 2024 at 7:19 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> On 7/4/2024 4:44 PM, Alan C. Assis wrote:
> > I think Greg avoided using submodules because there are many issues
> caused
> > by it.
> >
> > In fact submodules could avoid this issue, but maybe we could have some
> > marks indicating the last commit expected on apps/ to the current nuttx/
> >
> > This way if someone git pull the nuttx/ and forgot to git pull the apps/
> > the make will detect it and will ask the user to do it.
> >
> > I don't like this approach because it makes things more rigid
> (inflexible).
> > This is not something easy to fix.
> >
> > BR,
> >
> > Alan
>
> That coupling could cause problems with the separation of OS and
> applications. We've done a lot of effort to assure that the apps are
> totally independent of the OS and totally optional.
>
> In the past, apps, Documentation, boards, and arch were all submodules.
> Users hated the use of submodules and I would be hesitant to ever force
> that on users again. It really complicates and slows down progress when
> you don't know if a change is in the currently selected submodule or
> not. It basically requires a PR and merge or more per day to be usable.
>
>
>
> It sounds like submodules are a bad idea... ok, scratch that idea.
In the blog he said he didn't want a shell & etc so it sounds like he
doesn't know that he can have his own apps repo, or use our apps repo but
disable NSH and use his own program as the initial task. Also since he had
trouble with debugging on FreeRTOS we should point out that the NSH shell
and various builtins (if you enable these features) can be very useful for
interactively debugging your board.
All in all a good blog post and I think good feedback for us. We should
improve distclean (maybe force it to actually distclean no matter what the
current state is on disk) and we should improve documentation, especially
to teach what kinds of things you can interactively test with a shell, and
then disable the shell when no longer needed.
Cheers,
Nathan
Re: [OT] Moving to a RTOS on the RP2040
Posted by Gregory Nutt <sp...@gmail.com>.
On 7/4/2024 4:44 PM, Alan C. Assis wrote:
> I think Greg avoided using submodules because there are many issues caused
> by it.
>
> In fact submodules could avoid this issue, but maybe we could have some
> marks indicating the last commit expected on apps/ to the current nuttx/
>
> This way if someone git pull the nuttx/ and forgot to git pull the apps/
> the make will detect it and will ask the user to do it.
>
> I don't like this approach because it makes things more rigid (inflexible).
> This is not something easy to fix.
>
> BR,
>
> Alan
That coupling could cause problems with the separation of OS and
applications. We've done a lot of effort to assure that the apps are
totally independent of the OS and totally optional.
In the past, apps, Documentation, boards, and arch were all submodules.
Users hated the use of submodules and I would be hesitant to ever force
that on users again. It really complicates and slows down progress when
you don't know if a change is in the currently selected submodule or
not. It basically requires a PR and merge or more per day to be usable.
Re: [OT] Moving to a RTOS on the RP2040
Posted by "Alan C. Assis" <ac...@gmail.com>.
I think Greg avoided using submodules because there are many issues caused
by it.
In fact submodules could avoid this issue, but maybe we could have some
marks indicating the last commit expected on apps/ to the current nuttx/
This way if someone git pull the nuttx/ and forgot to git pull the apps/
the make will detect it and will ask the user to do it.
I don't like this approach because it makes things more rigid (inflexible).
This is not something easy to fix.
BR,
Alan
On Thu, Jul 4, 2024 at 7:08 PM Nathan Hartman <ha...@gmail.com>
wrote:
> On Thu, Jul 4, 2024 at 5:21 PM Alan C. Assis <ac...@gmail.com> wrote:
>
> > Nice post for a guy (apparently with previous Linux experience, that type
> > of person normally find their way well on NuttX) moving from baremetal to
> > RTOS:
> >
> > https://blog.brixit.nl/moving-to-a-rtos-on-the-rp2040/
> >
> > The issue he commented about "make distclean" not working is serious and
> we
> > need to find a solution to work transparently. Instead of cloning nuttx
> and
> > apps again and again as he just did, I just remove the .config and run
> > ./tools/configure.sh again without problem.
> >
> > But obviously it is not the ideal solution, we need to find a way to keep
> > apps and nuttx in sync or at least no mess with our users.
> >
> > BR,
> >
> > Alan
>
>
>
> Could do a third repository which uses nuttx and apps as submodules?
>
> >
> >
>
Re: [OT] Moving to a RTOS on the RP2040
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Jul 4, 2024 at 5:21 PM Alan C. Assis <ac...@gmail.com> wrote:
> Nice post for a guy (apparently with previous Linux experience, that type
> of person normally find their way well on NuttX) moving from baremetal to
> RTOS:
>
> https://blog.brixit.nl/moving-to-a-rtos-on-the-rp2040/
>
> The issue he commented about "make distclean" not working is serious and we
> need to find a solution to work transparently. Instead of cloning nuttx and
> apps again and again as he just did, I just remove the .config and run
> ./tools/configure.sh again without problem.
>
> But obviously it is not the ideal solution, we need to find a way to keep
> apps and nuttx in sync or at least no mess with our users.
>
> BR,
>
> Alan
Could do a third repository which uses nuttx and apps as submodules?
>
>