OSDev.org

Hello devs,

I'm trying to come up with the best design to define an "active process" for my OS, meaning the process that should receive input events, such as keyboard/mouse, and not the process that is currently running in the scheduler. I don't know exactly how Linux does that, so I'm lacking references to do my implementation. For now I'm thinking about a terminal-based OS, without any type of GUI/window system.

Currently, my OS invokes the bash as the first running process, and the bash is responsible for invoking other user-processes. My bash runs as an user-application. I was thinking of some approaches like:

1 - The bash is responsible for telling the OS about the process that should receive focus, maybe by making a syscall passing the process PID to the OS
2 - Each process can claim focus by making a syscall, but this seems like a bad design to me, since the bash loses control of the process that is on focus.

What is the most common approach for this problem? What do you suggest?

Thanks!

Just say "the shell" instead of "the bash"; bash is just one of many shells for command-line systems.

I've been using Unix system terminals for many years. I don't know all the internal details but I do know only 2 things get switched: program input and running/paused. Output from background processes gets merged which is fine if the output is in whole lines. Processes belong to the shell (the shell's "child processes") are called "jobs". There's only one "foreground job" which gets input. Other jobs see the same terminal as their input, but if they try to read from it they block. Somehow, the shell can tell they're blocked on input and puts them into "stopped" (paused) state. Ctrl-Z stops the foreground process, although it's possible for a program to intercept Ctrl-Z and then it must handle it itself. It's possible Ctrl-Z only works automatically if the terminal is in "cooked mode", and must be handled by the program if the terminal is in "raw mode", but I'm not quite sure. Anyway, cooked mode sends a line at a time, raw mode sends each key as it's pressed. This is mostly practical in use but one badly-behaved program can mess up the tty. Thus there are "reset" and "stty sane" commands.

I don't know the exact design, but I guess the kernel must be involved in deciding where input goes because a program might decide to read the device file representing its terminal. (Pagers do this. They get the text to be displayed from stdin and keys to go back and forward, search, etc, from the tty.) I think there must be a syscall or an ioctl to determine which process gets input. I'm sure the child processes don't claim input for themselves because all this works with programs which have no concept of the terminal, such as cat and sed. If you make it so the child processes need to claim input, then every program would need to be aware of the terminal. In summary: I think your idea #1 is the most practical.

Are you able to be clearer about the architecture of your Operating System?

felipeek wrote:Hello devs,
Currently, my OS invokes the bash as the first running process, and the bash is responsible for invoking other user-processes. My bash runs as an user-application. I was thinking of some approaches like:

1 - The bash is responsible for telling the OS about the process that should receive focus, maybe by making a syscall passing the process PID to the OS

This is similar to the way POSIX handles jobs. Any number of processes can be connected to a controlling terminal input/output via stdin/stdout, but a job aware shell will control which process group is the foreground process group, and therefore which process group can read/write to the controlling terminal. Background process groups will receive a SIGTTIN when they try to read from the terminal.

The foreground process group is set using tcsetpgrp

More information: Job_control_(Unix)

Note, access to the terminal is by process groups, and terminal signals will be sent by the controlling terminal to the foreground process group which may comprise multiple processes.

felipeek wrote: 2 - Each process can claim focus by making a syscall, but this seems like a bad design to me, since the bash loses control of the process that is on focus.

Yes, you want who gets the input under the control of some controlling process. In UNIX, input/output is generally via terminals, either terminals backed by a device (whether real or virtual device, such as the console or a serial terminal) or a pseudo-terminal (which is a software construct used by the likes of terminal emulators like xterm.)

When a new terminal session is created (via login, or creating a new terminal window) the user shell is run, and that shell will make itself the session leader. I don't recall off hand whether a process can make itself the foreground process, or whether only the session leader can change the foreground process group.

For some added context, the OP also posted this question on /r/osdev where I and others provided similar answers.