15-410 Project 4 Extended Console

If you choose to do the extended-console project, here is what we are looking for.

Virtual Consoles

• What "virtual consoles" means is that the single physical screen and keyboard are multiplexed by the operating system (that's you) so that it looks as if there are multiple instances of each one. That is, there will now be N screens and N keyboards as far as processes are concerned. Output routines such as print() will paint a virtual screen, which may or may not be visible, and keyboard scancodes will result in characters being available on various keyboard queues at various times.

• From the user's point of view, there should be multiple independent text consoles, and pressing the Tab key on the keyboard should switch the screen and keyboard "immediately" from one virtual console to another (by "immediately" we mean that this should happen as soon as practical as opposed to after the next timer interrupt, after the next getchar() completes, etc.

• Threads which share memory with each other (logically, i.e., other than via copy-on-write tricks) also share a single virtual console. Each newly created thread or process will begin using the same virtual console as its parent.

• If you may wish to use a different color combination for each virtual console, they must all be reasonable.

• A new system call, int new_console(void), should determine if the request for a new console is supportable, and, if so, should allocate an unused console and switch all further console I/O of the calling process (and its associated thread family) to the new virtual console.

• If any thread in a thread family has a console I/O operation already in progress, new_console() should fail.

• If too many virtual consoles are in use, new_console() may fail. You should support at least 4 virtual consoles.

• Once a virtual console has no more threads or proceses associated with it, it should be deleted from the Tab key rotation once the user has had a chance to view the contents once (it might be friendly for the kernel to somehow indicate to the user that this is the last viewing of the console).

• If nobody ever calls new_console(), the operation of the console/keyboard system should be as it was for P3. Also, processes should have no way of observing that they are not running on a P3 kernel without virtual consoles (aside from the behavior of new_console()).

  In case you're wondering, the number of lines available on the screen is not deemed to be a "P3 kernel property"--in theory a "P3 kernel" could have any number of lines on the console as long as the system call interface behaved correctly.

By the way, the Linux machines in the clusters support virtual consoles...press Control-Alt-F1, Control-Alt-F2, etc. Those virtual consoles are persistent rather than being created and deleted as we are suggesting for P4.

System Monitor

No matter which virtual console is active, the bottom-most physical line of the console should be dedicated to kernel status monitoring. Use your judgement and be creative here, but we would like to see most or all of the following areas addressed in a creative way (e.g., balancing the amount of information with the amount of screen space available).

1. Indication of which virtual console is selected.
2. Indication of system processor load.
3. Indication of memory usage.
4. Indication of scheduler status.
5. Periodic indication of time since boot.
6. Indication of system I/O status (think about what you can do here).

Have Fun!

Make sure to have some fun with this project. You've earned it, right?

[Last modified Wednesday November 26, 2003]