On Mon, May 18, 2020 at 9:07 PM Gregory Nutt <spudan...@gmail.com> 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 applications with ELF applications. That is a > recommended way for updating an embedded system. The original PR broke > that logic. > > 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 the built-in command with the same name, you'll > > have to increase the spawn stack size anyway !?!? > > 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 base ROM logic. Imagine that I have 100,000 products in the field > and I want to replace a built-in. That is pretty easy to do by just > writing the ELF file to the some local file system. You would like to > avoid replacing the entire FLASH image. > > And if it is not replacing an existing built-in application. Then there > is no information on stack size. The ELF format does have logic to > support a stack section, but that is not used by the loader. Other > formats do include the stack size as part of the header (NXFLAT, for > example). But otherwise, you have no option but to make the global > stack size larger for all applications. > > We could potentially come up with an extended ELF head that includes > stack and priority information. I think it could be done because the > offsets in the ELF header permit the header to be extended. That would > be a good project. >
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 system applicaiton How about we open a new issue track ELF extension for stack/priority? > > But that's for you pros to decide. > I merged Xiang's change. Please try the changes in the repository now > if you can make the time (without changing the name of hello). > > At least seems you got a communication problem here, because nobody had > > a notion about the impact of Chaos commit. > > Yes, a communication problem, a testing problem, a requirements problem, > many problems. You can help by contributing some time and effort to > make things better 8) > > Greg > > >
