What happens if you just compile the Linux kernel (plus the absolute bare minimum to get it to boot, but no tools) onto a system? Can it do anything at all? What commands are even available, if any?
The kernel of an operating system doesn't really do anything by itself; it's just an interface for hardware-software communication. There are no commands, unless you're a program interfacing at a system level. It's sort of like asking "what happens if you put a desk in a room"? Well, there's a desk in the room. You can put things on the desk, or I suppose you can sit on it, but the desk by itself isn't actually very interesting.
Edit:
But the closest is maybe Minimal Linux: https://distrowatch.com/table.php?distribution=mll
All you get is a shell with some limited tools, I don't know exactly which. But not a lot! Probably the place to go if you want to try compiling a kernel and seeing what happens, though, consensus seems to be it's great for tinkering with.
I get where you are coming from, but that is not explicitly accurate..
an operating system kernel most certainly *IS* the thing brokering all hardware accesses. That is one of its primary functions; but in a modern kernel, it has much more important functions:
1) Manage memory allocations and garbage collection
2) Protect important processes that interact with hardware resources, such that user mode software cannot meddle with them in dangerous ways, by abstracting *ALL* access requests.
3) Protect processes from each other, so that data does not get stolen clandestinely (such as from malware), does not execute at the wrong privilege level (eg, limited user cannot change system settings or modify other user's data), or does not inadvertantly cause problems (memory overflow outside of allocation, into next process's memory)
4) Provide standardized interfaces that user mode application developers can make use of. (Very important change from say, the 80s and 90s, when such abstraction was not performed, and lots of competing "defacto" standards were out there-- all different.)
While none of those things are "WOW! SO COOL!!", there most certainly is a lot more going on in there than an inactive, passive object like a desk.
It's a bit more like having a home automation system, that controls the roombas in your house. Not glamorous, but it does a lot more decision making than you would expect.
As for "Compile the linux kernel into $foo, would it be able to do cool stuff?" that is a nebulous question. The naked kernel just does the above things. It schedules tasks, protects and manages memory, enforces user security, and manages all connected hardware resources.
Without something ASKING it to do things though, it does indeed kinda just "sit there".
It gets nebulous though, because you can insert things INTO the kernel, as built-in modules. Those things can indeed do fully autonomous activities right in the kernel land.
As a rule of thumb, you should NOT put a system daemon inside a kernel module, unless it is managing some vital bit of hardware. EG, DO NOT put the TCP/IP stack inside a kernel module. It is not sensible, nor safe. However, it is entirely possible to say-- Shoehorn an entire small game server into the TCP stack, as a loadable module, and then technically it would be part of the running kernel. This is not advised. It is not normal. You should not do it, even though technically you totally can. (You can also put your genitals into an edison light socket, but it is likewise, very much not advised.)
I really mention this for things like say--- A consumer programmable robot kit.
Suppose you have a robot, into which you have incorporated some autonomous routines, so that the user does not have to explicitly call them. Such as say, "Fall avoidance" in a bipedal robot. There could be value in having this kind of very low latency code run immediate, in kernel process space, and have user program logic that controls the robot live in userspace.
Author
Topic: The small random questions thread [WAAAAAAAAAAluigi] (Read 687772 times)