So, in current git HEAD [1], what is the search order now?
Is it back to:
- Elf
- Built-in
- NSH
Or is it:
- Built-in
- Elf
- NSH
It is not so clean and well partitioned. It is more like:
o IF Built-in available
- Elf
- IF NOT Elf
Built-in
o Elf
o NSH
The logic is spread across
>
>
> That is true. The assumption is that the stack size of the built-in
> application will be big enough for the replacement ELF application.
> That might not be true. But in the case of replacing a built-in
> application with an ELF application, the rule is that we cannot
> modify
> the
So, in current git HEAD [1], what is the search order now?
Is it back to:
- Elf
- Built-in
- NSH
Or is it:
- Built-in
- Elf
- NSH
It is not so clean and well partitioned. It is more like:
o IF Built-in available
- Elf
- IF NOT Elf
Built-in
o Elf
o NSH
The logic is spread across a
On Mon, May 18, 2020 at 10:38 AM Gregory Nutt wrote:
> >> Yes, the best solution is to extend ELF with stack and priority info.
> >> But before that happen, gathering this info from the built-in app
> >> table is workable alternative:
> >> 1.Keep the trying order(file system, built-in and nsh comm
Yes, the best solution is to extend ELF with stack and priority info.
But before that happen, gathering this info from the built-in app
table is workable alternative:
1.Keep the trying order(file system, built-in and nsh command)
2.And get the stack/priority from built-in app table for file s
Yes, the best solution is to extend ELF with stack and priority info.
But before that happen, gathering this info from the built-in app
table is workable alternative:
1.Keep the trying order(file system, built-in and nsh command)
2.And get the stack/priority from built-in app table for file sys
On Mon, May 18, 2020 at 9:07 PM Gregory Nutt wrote:
>
>
> > OK, by now I'll keep using the alternative to use another name for the
> > elf app/FILE_APPS, as seemingly intended by
> > chao.an in his commit.
> No, that was an error. The requirements have always supported
> replacement of built-in a
OK, by now I'll keep using the alternative to use another name for the
elf app/FILE_APPS, as seemingly intended by
chao.an in his commit.
No, that was an error. The requirements have always supported
replacement of built-in applications with ELF applications. That is a
recommended way for u
Hi all,
OK, by now I'll keep using the alternative to use another name for the
elf app/FILE_APPS, as seemingly intended by
chao.an in his commit.
I don't really understand Chaos solution because if the ELF app needs a
bigger stack, which is quite probable because it is a
derivation/evolution of
Hi Greg,
About the break commit:
commit 9a28ccf836c1b9f0eb5e1163964042eddc207697
Author: chao.an
Date: Fri Feb 21 09:54:47 2020 +0800
nsh/parse: try the builtin configuration first
In the case of enable the BUILTIN_APPS/FILE_APPS at the same
time, try t
10 matches
Mail list logo
