Isn't the kernel idle loop a gets(str)?

[~]

It seems to me that the kernel idle loop is simply waiting for user input.

The mouse has an interrupt handler, outside of the loop.

The keyboard is handled at the idle loop to process a command line, so it implies that it's basically a call to gets()

The PIT also has an interrupt handler, also outside of the idle loop.

Few things wake up the idle loop, specially if it has HLT instructions, mostly the keyboard's command line that ends with an Enter, just like gets(). From there, anything else would be a deviation to a function or another process, but the idle loop would always serve as the handler for the program in front of the user (or background keyloggers).

[bzt]

It seems to me that you're confused about a couple of things.

First, gets() is a library function, which under the hood uses the read() function on the standard input. The read() function in turn does a system call to the kernel. Then when the kernel sees that the input buffer to the process' stdin is empty, it puts that particular process into a blocked state. So far this has nothing to do with the kernel idle loop.

Next, there's a part in the kernel which is called scheduler, that is responsible to pick a task to run. It only picks from the active processes (and our blocked process is not one of them any more). When the active task list is empty, and there's no process to pick, then and only then the scheduler picks a special "process", which is the kernel idle loop. That loop usually issues a "HLT" instruction to put the CPU at ease until an interrupt fires. When that happens, then the kernel checks the blocked list, and if there's new data for one of them, then it activates that process. The activated process now has something in its input buffer, therefore when the scheduler picks it, it will be able to continue, and read() will return what's in the stdin's input buffer, and with that gets() can also return. In a nutshell.

So the kernel idle loop does not wait for user input at all. It could be interrupted by a clock interrupt for example, or by a network card interrupt. User input devices are just a subset of devices that may trigger an interrupt. There are many other, not user-related peripherals you know.

Cheers,
bzt

[iansjack]

The "idle loop" doesn't have to be idle (i.e. just a "hlt"). It can also be used - as a task with lower priority than any other - to do background maintenance work, e.g. checking allocated memory for any that is no longer referenced and freeing it.

I'm afraid the OP demonstrates a profound lack of understanding of how tasking works.

[Ethin]

I'm of the opinion that the OP (unfortunately) demonstrates a profound lack of understanding about everything to do with OS development. Thus far I have not seen any posts from them that contain any actual questions about it, or information that is actually useful, to current or future OS developers. I probably would've fallen into the trap of listening to them when I first joined this forum, but fortunately for me they gave me entertainment instead with their hole "full BIOS emulation layer" thing in UEFI firmware topic a few months back. I'm seriously starting to wonder if they do it just to troll.
Other than that... I have pretty much nothing to add to what has already been said here. My kernel idle loop is an endless loop of "hlt"'s. "hlt" is far different from "gets".