I understand that the maintainers have very limited time in their inventory but I think there might be some confusion here
The MR has no relation to GSoC. I am trying to port microshell apart from my GSoC proposal as a separate thing to get a better understanding
The primary reason for opening the MR (draft) was to ask questions while referencing the code itself. In the MR, I asked a few questions which directly refer to different parts of the code. Having that allows for better clarification in my opinion, since the reviewer can see the actual problem instead of me trying to explain it haphazardly
That being said, please let me know if this approach is not desirable
What Gedare said has not changed here. It’s better to open an issue and propose a change to discuss it there. In this case discuss it on the project issue.
Talking about it in an MR doesn’t make sense as most of the conversation would surround code that does not exist and reference already existing RTEMS code. Bringing in microshell itself would be the last step.
I would suggest closing it, although most of us will just ignore it in draft state. It is much better to discuss the questions etc. either here or in the relevant issue, as Amar said. There is little value in us spending time looking at 4.5k LOC patches for work-in-progress to try to give guidance.
I have been looking at the MicroShell codebase. The port comes down to implementing ush_read and ush_write against RTEMS console I/O and wiring them into ush_io_interface. The shell descriptor also needs static buffers for input/output and a mount point for at least the root directory. No fork or exec anywhere in the model, which is exactly why it fits RTEMS.
I have set up the build environment SPARC, and have a hello world running on the simulator. Next step is getting MicroShell compiling under RTEMS and writing the I/O layer. I would appreciate your help
Hi guys,
I am Lawrence S. Peterson, CS student in Ghana, and very comfortable with C and Python.
I went through the existing thread and also looked at the draft merge request that was opened. I can see microshell has already been gotten to run on RTEMS, but there are still open questions around how the build should be set up, specifically whether it should build conditionally or always, and where the platform config header should live. I want to make sure my proposal addresses these properly.
I just built RTEMS 7 from git, cross-compiled for arm/xilinx_zynq_a9_qemu, ran and modified the hello world sample on QEMU.
Given that the existing draft MR embeds microshell directly inside rtems.git, but the project description also mentions RSB packaging as a possible path, which approach would you prefer for this project? I want to make sure my proposal is targeting the right integration strategy before I write it up.
Hi @gedare, I have drafted my proposal for the microshell port project and plan to submit it before the deadline. Happy to share it if you have time to give feedback before then. Is there anything specific you would want to see addressed in the proposal scope?
