Re: Builtin app with its own command processor on stdin

[spudaneco]

My guess would be stack corruption.  Crashes and hangs often don't happen until 
the app exits,  I would try increasing the app stack size.Sent from my Galaxy
 Original message From: Jernej Turnsek 
 Date: 1/24/24  1:12 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: Re: Builtin app with its own command processor on 
stdin Hi Alan,I have meant my app is processing its own commands as long as the 
quitcommand is entered or CTRL-C is pressed.BR,JernejOn Tue, Jan 23, 2024 at 
9:15 PM Alan C. Assis  wrote:> Hi Jernej,> by not returning 
to NSH do you mean after pressing Ctrl+C ?>> Maybe this tutorial will help:> 
https://www.youtube.com/watch?v=hszt15lTsnA>> BR,>> Alan>> On Tue, Jan 23, 2024 
at 4:56 PM Jernej Turnsek > wrote:>> > I am running 
an app in the foreground. I didn't have waitpid enabled.> Now I> > have and it 
works as it should.> > BTW, my app is not exiting to nsh. Thanks.> >> > On Tue, 
Jan 23, 2024 at 7:38 PM Gregory Nutt > wrote:> >> > > Are 
you running app in foreground or background from NSH, i.e.,> > >> > > nsh> app> 
> > nsh> app &> > >> > > The second should show this kind of interleaved 
behavior.  In the> first,> > > nsh should block until the app exits.> > >> > > 
Do you have waitpid() enabled?  The first behavior depends on the> > > 
availability of waitpid()> > >> > > Does you app exit and return to nsh after 
each command?> > >> > > On 1/23/2024 11:19 AM, Jernej Turnsek wrote:> > > > 
Hi,> > > > I would like to develop my own builtin application to process some> 
> custom> > > > commands. This app is started from nsh over the serial console. 
I> have> > > > duplicated the code from ftpc example and when application is 
started> > it> > > > start to process stdin for commands. But this 
functionality is mixed> > with> > > > nsh own processing of commands, thus when 
I hit Enter, I get app>> line,> > > > when hit Enter again I get nsh> command 
line. Entering commands like> > > > "help", I get hl on nsh and ep on my app 
command processor. I am> > confused> > > > here. I did not test ftpc example, 
but I presume it is not working> > > either.> > > > Both apps are using 
readline_stream API for getting the commands.> > > >> > > > Regards,> > > > 
Jernej> > > >> > >> > >> >>

On-demand paging and lazy loading on NuttX;

[Tiago Medicci Serrano]

Hi!

The topic is *on-demand paging and "lazy loading" on NuttX*.

Well, the on-demand paging article
 (and `
CONFIG_PAGING
`)
seems to have implemented the dynamic loading of instruction sections
(*.text) from a non-volatile media to internal RAM (able to execute
instructions). This was done mainly for LPC31xx and stated that it isn't
complete yet (a kind of experiment) and it does contain a page fault
handling logic.

On the other hand, one could use the Shared Memory Support
 mechanism of
paging allocation to implement on-demand paging. It even states that:

> NOTE: An improved implementation my perform a “lazy” back up of the
> physical memory, i.e., do not allocate the physical memory until the memory
> is required, for example, when a page fault occurs when a application tries
> to allocate the memory.
>

But lacks the "page fault" mechanism to provide a newly mapped page for the
task that caused the exception.

I may be missing something about this subject, but have you thought about
it? The idea is to allocate bigger virtual memory to the tasks' stack (with
few mapped pages) and treat page fault exceptions when they occur (and
freeing physical memory when it isn't needed anymore, making it possible to
be mapped to other pages if needed). How far are we from providing that?

Any thoughts about it?

Best regards,

-- 
Tiago Medicci Serrano

Embedded Software Engineer
MSc Electronics/Microelectronics
m: +55 (19) 981403886 <+55+(19)+981403886>
e: tiago.medi...@gmail.com
a: Campinas, Brazil
Follow me:

Re: On-demand paging and lazy loading on NuttX;

[Gregory Nutt]

The on-demand paging logic is obsolete and incomplete as well as 
incorrect for the current architecture.  It was an experiment only for 
the LPC3131 when I was running out of a small SRAM with dynamic paging 
from SPI flash.  It really should be removed.


True on-demand paging as you envision should be implemented in the 
context of the kernel build mode (which did not exist in the time frame 
of the LPC3131) which already supports dynamic paging of the heap, but 
not the stack or instruction space.


There is also: 
https://cwiki.apache.org/confluence/display/NUTTX/On-Demand+Paging


On 1/24/2024 2:14 PM, Tiago Medicci Serrano wrote:

Hi!

The topic is *on-demand paging and "lazy loading" on NuttX*.

Well, the on-demand paging article
 (and `
CONFIG_PAGING
`)
seems to have implemented the dynamic loading of instruction sections
(*.text) from a non-volatile media to internal RAM (able to execute
instructions). This was done mainly for LPC31xx and stated that it isn't
complete yet (a kind of experiment) and it does contain a page fault
handling logic.

On the other hand, one could use the Shared Memory Support
 mechanism of
paging allocation to implement on-demand paging. It even states that:


NOTE: An improved implementation my perform a “lazy” back up of the
physical memory, i.e., do not allocate the physical memory until the memory
is required, for example, when a page fault occurs when a application tries
to allocate the memory.


But lacks the "page fault" mechanism to provide a newly mapped page for the
task that caused the exception.

I may be missing something about this subject, but have you thought about
it? The idea is to allocate bigger virtual memory to the tasks' stack (with
few mapped pages) and treat page fault exceptions when they occur (and
freeing physical memory when it isn't needed anymore, making it possible to
be mapped to other pages if needed). How far are we from providing that?

Any thoughts about it?

Best regards,

Re: On-demand paging and lazy loading on NuttX;

[Gregory Nutt]

On 1/24/2024 3:44 PM, Gregory Nutt wrote:
The on-demand paging logic is obsolete and incomplete as well as 
incorrect for the current architecture.  It was an experiment only for 
the LPC3131 when I was running out of a small SRAM with dynamic paging 
from SPI flash.  It really should be removed.


True on-demand paging as you envision should be implemented in the 
context of the kernel build mode (which did not exist in the time 
frame of the LPC3131) which already supports dynamic paging of the 
heap, but not the stack or instruction space.


There is also: 
https://cwiki.apache.org/confluence/display/NUTTX/On-Demand+Paging


There is also this better reference: 
https://cwiki.apache.org/confluence/display/NUTTX/Memory+Configurations 
.  It address both the on-demand paging featured (briefly) and compares 
this to Kernel mode (in depth).