On Fri, Jan 10, 2020 at 1:36 PM G. Branden Robinson
[I added a subject to the thread.]
At 2020-01-10T15:19:17+0300, abdi mahmud haji wrote:
hey guys I'm abdurahman and i have same question for you i have been studying microkernel for a little well now specially seL4 and i have done almost every tutorials in sel4 -tutorials and i have a crazy idea ,that is i when try to build a 'shell or prompt' on the seL4 mircokernel but i don't have any idea how to do or where to start . does any one have a suggestion for me
Hi Abdurahman,
Hi all, I'm not really affiliated with the sel4 project, but also wanted to chime in on the subject. I don't think enough ink has been spilled on it. Branden's response focused on a lot of things which don't belong in the microkernel itself, and I totally agree. I want to focus on designs for a "native" shell for a capability system rather than anything which is going to be resembling a posix shell. There is a picture here, on page 24 describing the various trust layers involved in the eros-os shell mechanism[1]. [1]:( https://www.cl.cam.ac.uk/teaching/2003/AdvSysTop/Capabilities.pdf ) This implements what i'm going to call a "pull model". The green Open/Save agent represents a power box, and the arrows from the red applications have a reference to this capability through which they request resources. Through this mechanism, you basically just start up the process, and give it that power box reference. At this point the program becomes something akin to it's own sub-shell through which it acquires arguments. This saves the shell(or user) from having to know about each message expected by the process, and the contents of each capability register. This would be what i'll call the "push model". In the push model we could even drop the powerbox, and the shell sends messages to the red process, perhaps without even a way for the process to send messages back to the shell. I think from the perspective of sel4, we can consider what he calls "SystemTCB" would correspond to sel4's "root process". The green window system, being IO. The simplest directory being an array or vector of (string, capability) pairs. For the green "Window system", i'm considering this basically nothing fancier than a terminal IO multiplexer. That is it's the thing receiving keyboard interrupts, which has some control mechanism for switching which process is currently receiving input. eTerm seems to be the process receiving input from the Window system for the shell. This is likely because eros did not have asynchronous notifications, and so you needed to spin up another process to avoid the shell being blocked, with sel4 we can likely roll this process into shell directly (with async notifications), maybe there is a reason to keep it separate that I can't think of. Using the pull model it would seem you greatly simplify the shell itself, that complexity ends up in the input/output interaction. Where the user is now interacting with multiple processes (the shell, powerbox, and untrusted process). I'm sorry this is all rather hand wavy, I have in the past had a go at implementing a simple terminal multiplexer for "Window system", It's not compiling with recent sel4's, but can have a go at updating it if that is of any help. There may even be one available in sel4 repositories somewhere by now, i am not sure. In my opinion starting out with the pull model is the quickest way to a working shell, interleaving output from each process into the output stream, and switching which application has the input cursor during program startup/option specification/argument passing, between shell/program/powerbox. Which tends to reflect how graphical applications run, formatting messages to themselves and calling system API's for filesystem dialogs. a "native" shell for systems like sel4 might be a very different beast than a unix-like shell which only ever passes arguments through initial argv. But in a system like sel4 it should be no problem to startup programs with zero, or only potential access to request capabilities, before we even know which arguments to pass it -- relegating the shell to starting up all programs with the same startup sequence. This doesn't actually give you any form of persistence/filesystem for our directory capability, but that is a whole other topic, and you can implement a shell without it. This has probably gotten too long, there is lots of details missing, like how we get such a thing to resemble the familiar interface a shell provides. It would probably also be helpful if i tried to write it in a non-email format where I could embed diagrams and the like, for visualizing the separate models independently of one another. But let me if I can clarify things or how I can help.