I am interested in contributing to the Port MicroShell project, as described in Issue #5312 .
I understand that the baseline task is to get MicroShell running with the built-in commands, and that porting RTEMS-specific commands can be an additional exercise to extend the project scope.
I would like to ask if there are any mentors assigned to this project who could provide guidance during the process. Additionally, I would appreciate any documentation or resources on how to port existing software to RTEMS, as this will help me plan my approach effectively.
Could you also provide guidance on how to structure the work and tackle potential challenges? This would help me understand the full scope and create a realistic timeline for my proposal.
There was work on this as part of GdOC last year. Offhand I do not know the precise progress point on this. You will need to assess that and see what else needs to be done.
The vision I had for interpreted languages on top of RTEMS long ago was that the language should be ported and functional and built with the RSB as a baseline. There should be an example showing this and appropriate user level documentation. All changes needed to the language should be upstreamed.
Then there is the issue of better integration with RTEMS. Make existing RTEMS shell commands accessible from the interpreted language with low integration effort. Again user level examples and documentation is needed for this.
Perhaps it makes sense to make some rtems APIs available from the interpreted language. This would likely be focused on specific areas. AFAIK no API has been identified as appropriate for this. This is not to say that doing this is wrong or stupid, it is just that some APIs are abstracted already through the interpreted language and don’t make sense to directly map. But there may be apis that make sense to do this to. These apis would need to be from the set that are not hardware specific.
My idea is to go from basic integration to more features available. But always being user focused on what is useful, packaging, examples l and documentation
I am confused as to what you mean by “interpreted language” in the context of the microshell port? Microshell does not provide an interpreter with it as far as I know. I am working on this issue and was able to get microshell to run under rtems as I showed in this post recently. Libraries' API design guide?
it works very similar to the existing shell except that it requires users to mount at least 1 path explicitly.
And in terms of apis, I think it should be as similar to the default shell as possible. So that documentation can be shared among the two.
Also, a side note, it’s weird to me that this project comes under the small category and not medium :?
Hey are you actively working on this project ?
how far have to covered it ?
and also i think by interpreted language it means a seperate library or tool which can be used just like microshell.
@JoelSherrill i was wondering if there is a reference for the proposals or like templates which i can use as an example for my own proposal , as it would help a lot
Porting software that “just works” tends to be a small project by itself. Adding more to it, or if the porting has some complications to resolve, can increase the scope.
so just running the basic commands after integrating microshell in rtems is sufficient for this project? or maybe i was thinking we can ship the microshell along with the rtems toolchain installation in a way that when we install toolchain for rtems the microshell is also configured for it by default so the users have more flexibility to choose the shell !
Yes, getting the basic microshell working in RTEMS and integrated somehow, whether that is through building it inside of rtems.git, or adding it as a package that gets built with the RSB.
It would be good to see how it runs and and what it offers. If it works and is good we can look to integrate it more deeply into RTEMS.
The RTEMS shell is stable and robust but not easy to maintain and lacks some important features you expect in a shell these days. The most obvious is scripting logic then there are other things like completion. Completion is hard because it tends to extend into a command’s implementation.
The command struct layout we have has issues around initialization. I have fixed some of the problems however there is a concern it is still a little fragile. The struct has fields I have never seen used. A new shell would need to provide support for existing commands as implemented and then over time I would like to migrate away from the current command structure deprecating it. This would impact users. Maybe we should also look at the monitor code and commands and what we do with them?
The RTEMS shell supports terminal size detection, ie LINES and COLUMNS setting of environment variables. This was hacked into the shell as there was no obvious place in RTEMS to handle this. We would need to maintain this support in a new shell. I am happy to look at other ways to implement this support. Maybe this is a new project on it’s own?
Hmmm, firstly i am going to run the basic commands microshell has to offer , because stability and integration into rtems must be kept for later implementations . I agree with you that considering the scope of this project it is going to be a new project on it’s own
can you tell me more problems in detailed , we are currently facing with the rtems shell. and i am kind of curious that why are we not using any other shell software’s available in the market?
I would encourage you to avoid opening an MR until you are ready to have the code reviewed. In this situation, you should be working toward developing your proposal based on what you figure out independently. Mentors have limited time/bandwidth to review code or work-in-progress. We can give feedback on the proposal itself based on what you learn on your own.