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 couple of files so is not in one place
anymore. It is not pretty, but seems like it should work.
The only advantage is in this case:
o IF Built-in available
- Elf
For built-ins, we have task stack size and priority information. For
o Elf
But we do not and have to use a default stack size which will be most
certainly wrong. We are contemplating fixing that via
https://github.com/apache/incubator-nuttx/issues/1065
I am not sure how Xiaomi deals with the stacksize and priorities now.
From looking at the implementation in apps/build/exec_builtin it looks
like they might have "fake" built-in tasks that have a stack size and
priority but but a NULL main entry point function. Then the look-up for
the built-in task finds the stack size and priority but no entry point
so it uses that stack size and entry point when loading the ELF file
instead. In this use case the built-in app entry is just used to carry
the stacksize and priority.
Clearly, the binary file itself would be a much more appropriate vehicle
to do that. This could all benefit be a better, cleaner functional
partitioning.
The problem with the original implementation was that it did not try the
ELF binary UNLESS that entry point was NULL. That was an error and
prevented the replacement 'hello' from working because there as an entry
point. PR 258 restored the order before 255 and fixed the logic error
in exec_builtin().
