OSDev.org

Hi, Guys,

I am new here and I wanted to ask this question on how to add a shell? I already created the kernel using the Bare Bones tutorial but now I want to add a shell to the kernel The Wiki doesn't really explain on where to put the code do you add it to the kernel.c or do you have to make a separate file for it?

Hope you guys can help me

do you add it to the kernel.c or do you have to make a separate file for it

That's completely up to you.

I would actually suggest to avoid putting a shell inside your kernel. Instead focus on the important things like virtual memory, VFS and userspace processes. Then you'll be able to make the shell a user program.

beachkid wrote:Hi, Guys,

I am new here and I wanted to ask this question on how to add a shell? I already created the kernel using the Bare Bones tutorial but now I want to add a shell to the kernel The Wiki doesn't really explain on where to put the code do you add it to the kernel.c or do you have to make a separate file for it?

Hope you guys can help me

You need to create

- userspace processes
- ways to spawn them
- ways to communicate between them
- ways to use libraries, preferably shared ones so you don't waste memory when mulitple processes are running
- terminal drivers that could work with multiplexed i/o from many processes in some way (both input and output)
- make one process (a shell) do user input and spawn other processes in response to user commands, connect communication channels between child processes and itself and be able to control their execution

easy-peasy

Do you have a keyboard driver?

Hi,

beachkid wrote:I am new here and I wanted to ask this question on how to add a shell?

Typically the OS provides various interfaces for user-related devices (keyboard, mouse, video, sound, etc); then you have a layer that talks to all of these (e.g. "X server") that is designed for modern event-driven user input (and not character streams) and modern (graphical) output; then you have some sort of terminal emulator layer (that may or may not run inside a GUI) that acts as a kind of a bridge between "modern, event-driven, graphical" and "antiquated character stream". Finally, after all of that, you have "shell".

beachkid wrote:I already created the kernel using the Bare Bones tutorial but now I want to add a shell to the kernel The Wiki doesn't really explain on where to put the code do you add it to the kernel.c or do you have to make a separate file for it?

For all of the pieces I mentioned above; the device drivers are the only pieces that really belong in a kernel (and even then micro-kernel advocates would say device drivers don't belong in kernel either). Mostly; if all you have is "example/tutorial code cut&pasted from barebones" then you probably have less than 1% of the things you need for a real shell.

What you probably want is some kind of (temporary?) "kernel debugger thing" that you can use to interact directly with the kernel while you're spending then next several years implementing all the things you need for a shell. For this sort of "lean and mean, not a shell" you probably only need a keyboard driver (and all the stuff it depends on), a "generic frame buffer video driver" (and all the stuff it depends on), and (optionally?) some code to convert characters into pixels.


Cheers,

Brendan

The Bare Bones kernel won't actually get you very far. I recommend you go to http://wiki.osdev.org/Meaty_Skeleton instead. There it gives you a nice code organization example, as well as plenty of reference links to other places that you will need to go (such as OS-Specific Toolchains) (http://wiki.osdev.org/OS_Specific_Toolchain)

I am new here,too!

MajickTek wrote:The Bare Bones kernel won't actually get you very far. I recommend you go to http://wiki.osdev.org/Meaty_Skeleton instead. There it gives you a nice code organization example, as well as plenty of reference links to other places that you will need to go (such as OS-Specific Toolchains) (http://wiki.osdev.org/OS_Specific_Toolchain)

I actually switched to the meaty skeleton it does it better than the bare bones

Unfortunately, neither of those articles cover anything related to actual OS development. They simply show you how to create an image that GRUB can load, and there is example code for presenting text on the screen and an implementation of a few common standard C library functions. This may constitute a basic starting point to quickly start experimenting from, but the rest is up to you.

Obviously, you can't implement a shell or user mode at this point, since there is nothing for user programs to actually use. I recommend starting by implementing threads and synchronization, as well as some form of memory management, since almost everything else will depend on these.

Perhaps a bit more digging is called for. You say you have covered both Bare Bones and Meaty Skeleton, correct? Now, as Gigasoft states, the first of those only brings you to the point of booting a stub of a kernel from a GRUB, while the second focuses on providing some examples of how to fill in specific details such as kernel-level text output and some of th common standard functions which you might want to use inside your kernel as you develop it.

The first thing to understand is that, even with Meaty Skeleton, this is just a jumping-off point. It give you just enough information to be ready to start writing an OS, but it really isn't showing you anything of how to do that yet.

Second, even in the parts they cover - the parts that vary the least from one OS to another - it is still very much meant as an example rather than a guide, showing you one way to do it.

Third - and this is the part a lot of people get caught on - the example implementations of 'standard' functions described as 'libk' are meant for use inside the kernel, and are only very, very minimal sub-set implementations for the most part. They are not the versions you are going to want to provide to applications, if only because they often rely on kernel-level access to hardware. Again, they are examples, but specifically they are examples of how you would do them if you have direct access to the hardware, as the kernel does. They are meant to give you those functions in the kernel itself, and while they may have the same names and interfaces as the Standard Library functions, they aren't the versions that the kernel will expose for general users - the 'libc' versions, which are selected using preprocessor directives, have mostly been stubbed out, because in order to provide them, you would need to have a method for system calls in place - and those are going to be different for different operating systems.

Finally, there's question of why you want to work on a shell at this early stage in the first place. I am guessing that by 'shell' you are not talking about a user shell in the usual sense, but rather what is known as a kernel monitor - something that would allow you to interact with, tweak, test, and debug the kernel as it is, or at least display what it is doing.