First and foremost, i know what a shell, kernel is. Now the dilemma.

Today i had my systems viva in college. The examiner asked me is there a shell between the hardware and the kernel. Obviously, i said no, and the gave the usual explanation that the shell is an interpreter, it takes the user input, interprets the command and communicates with the kernel via system calls.

He then says what if i say that there is a shell between the hardware and kernel. I said it can't because there is no point. The job of the kernel itself is to interface with the hardware why will the shell be involved.

Then he started arguing that kernels are itself a set of programs, the how can they run another program. Now i got confused.

So if anyone could clear my query that whether a shell exists or not. And the biggest one, how can a kernel run a program. Is it because the kernel is in memory and its starts the init process and all other programs are run by it

  • 1
    $\begingroup$ Well, with a loose enough interpretation of shell, there is that. Though I assume your answer was correct and the examiner was merely exploring your confusion. Wikipedia says A program is a sequence of instructions, written to perform a specified task with a computer. What part of that prevents the kernel from being a program? $\endgroup$ Jan 10 '14 at 19:43
  • $\begingroup$ Shell may also be interpreted as a Hardware Abstraction Layer (HAL), which is present to some extent in most OSs that target multiple hardware platforms to create some uniformity in development between platforms. However, this is by no means necessary; the kernel can itself be the "shell". $\endgroup$
    – chbaker0
    Jan 10 '14 at 23:59
  • 1
    $\begingroup$ Perhaps the examiner meant "shell" as in "layer", rather than "command interpreter"? But we're basically clitching at straws, here. Try asking your professor or the examiner. $\endgroup$ Jan 11 '14 at 10:23

Given the details you have given us, you are of course right. There is no shell between the hardware and the kernel; that's just silly. Asking "but what if there were?" would be like asking "but what if pigs could fly?".

It is likely that either there was some misunderstanding or that the examiner is confused. The former is much, much more likely.

One thing I might critique is your characterization of a shell as an interpreter. While a shell is an interpreter, not every interpreter is a shell. I suppose it is possible that the examiner was asking a follow-up question to see if you understand that.

As far as how a kernel runs programs.... read a standard operating system textbook. The details are adequately covered in any standard OS textbook.

The thing is... I'm not sure why you're asking us. Why not ask your professor or examiner? We can't tell you what was in your examiner's head.

  • $\begingroup$ Well i met him for a viva so I'll never meet him again, plus he creeps me out i mean who knows what he says to shake my brain again :D $\endgroup$ Jan 27 '14 at 18:10
  • $\begingroup$ See RFC 1925, pigs fly just fine. $\endgroup$
    – vonbrand
    Mar 13 '14 at 18:39

Most kernels do not talk to hardware directly unless you are talking about a monolithic kernel. Instead, with a micro-kernel architecture a system will use kernel loadable modules (device drivers). So now we can argue about the distinction between the kernel and a device driver - Does the kernel talk to hardware directly if it must go through a device driver? The reason this question is important for your question is because we have to see if we can in any way categorize the way a kernel talks to hardware as using a shell.

Shell requirement 1 - A text based interface that translates a string or series of strings into some action. I'm not sure this is even a requirement of a shell. A Unix CLI translates text but a shell doesn't have to be a CLI. However lets consider it a requirement anyway. Device drivers most definitely can do this. The category of device drivers known as char or character devices receive text and interpret it. How you would implement the device_write method in a char-based device driver - http://www.tldp.org/LDP/lkmpg/2.4/html/x579.html

If being a text interpreter is the only requirement then yep, there is a shell between the OS and hardware.

Shell requirement 2 - A different address space or process. It could be argued that even in a micro-kernel that the char device drivers become a part of the kernel when loaded. If a shell is a layer that forms a separation or boundary between components then a same address space device driver really only has a boundary that is defined by a method call which isn't much of a boundary at all. Can you have a device driver that interprets text AND is in a different address space than the kernel? Most definitely - while not the norm yet if you look into microdrivers or user-space device drivers you'll find that they do exist.

Shell requirement 3 - Purpose. If a "shell" is just a layer around something that is communicated with via a sequence of text then there are shells around hardware. As the most common type of shell that users have interfaced with is a Unix CLI the description of a shell has often been corrupted to describe a Unix CLI instead of the more generic idea of a shell. So if a shell is just a layer around something, yes you have a shell around hardware. If you want to compare it more to a Unix CLI well then my 1st and 2nd requirements above get us most of they way to being similar to a Unix CLI so whats left?

Handle user input - Your examiner asked about a kernel -> hardware shell so I'd argue that handling user input was not in their requirements list of a shell. However would the user ever submit text to a hardware device driver? Maybe...old modems required a series of AT commands to correctly initialize them.

Limited actions - Another characteristic of a shell that is really a Unix CLI characteristic is the translation of user text into system calls - a Unix CLI is really about providing a way to convert text into syscalls and is the users interface to the kernel. So I'd argue that a device driver is not a shell in the Unix CLI sense because it doesn't exist to convert text into system calls (although some syscalls like sprintf might get used).

TLDR; A device driver is a shell but not a Unix CLI.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.