patacongo commented on issue #5811: URL: https://github.com/apache/incubator-nuttx/issues/5811#issuecomment-1073977417
I did the very original KERNEL build logic, lots of changes have happened since that I am not aware of so, unfortunately, I am probably not such a technical source. I considered the KERNEL build a work in progress and there is a roadmap document that describes what all of the final steps would be to complete the a wold-class solution: https://cwiki.apache.org/confluence/display/NUTTX/Memory+Configurations You can see the "Line" in the center of the document. Below the "Line" are features that have not been implemented. I think that the problem that you describe here would best be fixed by continuing to implement features on the roadmap. That might take a little bigger effort but has better payoff in the future than simply. I think that the problem that you are describing here is really as consequence of a missing feature: "Dynamic Stack Allocation. Completely eliminate the need for constant tuning of static stack sizes.(not implemented)." If each thread's stack is dynamically allocated on-demand, then there can be no initial stack size issue. In this case the solution would work something like this: - The virtual address space would need to be reorganized to make space for virtual stacks for the main thread and all possible pthreads. It has been a long time since I looked at MIPS Linux, but it used to reserve the top area of memory for virtual stack. As I recall, each virtual stack region was 2 Mb. That is large, but does not cost any "real" memory since this address spaces is not backed with real memory. - When the process is created, a single page is allocated for the initial stack at the "top" of this virtual address space. - Additional pages are added as needed whenever there are stack accesses beyond the mapped address space (via a page fault exception handler). Another benefit, of these large virtual stack spaces is that TLS can be greatly simplified: Simply ANDing the current stack pointer by the size of the virtual stack address spaces gives you the TLS base address. That can be done in user space! The argument against doing this and, instead, just patching up the existing logic is that this is more work. But this also takes the KERNEL build a lot further along on the Roadmap to full process support comparable to Linux. If you are willing to solve this "the correct way", I would be happy to help you in any way that I can. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
