I would say something a little different. The kernel is a _library_ that has an init routine you can provide the function for. Or put another way, without the kernel your go program would have to have drivers statically compiled into it. This was the world of DOS, btw.

▲

sedatk 4 days ago | parent | next [-]

I agree with your point, but I must correct you on DOS: it had device drivers too. :) That's how we used to access mouse input, CD drives, network, extended memory, etc. Yes, it sucked on the graphics and sound; every app basically had to reimplement its own graphics and audio layer from scratch, but the rest was quite abstracted away.

	▲	1313ed01 4 days ago \| parent [-]
		There were generic VESA SVGA drivers towards the end of the MS-DOS era. Sound blaster(16) also came close to being standard enough that games could just support that. Extrapolating I think MS-DOS was on a nice trajectory to having complete enough (and reasonably simple and non-bloated!) APIs for everything important, when it was killed off. Late MS-DOS 32-bit games were usually trivial to install and run.

▲

charcircuit 4 days ago | parent | prev [-]

More importantly, a kernel is a platform. Conceptually it isn't that much different than other platforms such as Chrome or Roblox. They all have to care about the lifecycle of content, expose input events to content, allow content to render things, make sure bad things don't happen when running poorly programmed or malicous content, etc.

▲

zsoltkacsandi 4 days ago | parent [-]

> More importantly, a kernel is a platform.

Completely agree with this framing. We will get there by the end of the series.

▲

tosti 4 days ago | parent [-]

Yeah no. An operating system kernel doesn't just act as a host for userland processes, it interacts with hardware. Hardware behaves in weird and unexpected ways, can be quite hard to debug, can fail, etc.

This is why Linux is excellent. Users of other operating systems often remind people to update their device drivers. A non-technical Linux responds asking what the heck device drivers are. To the casual user, device drivers become invisible because they work exactly as intended.

▲

charcircuit 3 days ago | parent [-]

The kernel talks to the device using an API it exposes. Similarly Chrome will talk to the OS using an API it exposes. OS APIs can also behave in weird and unexpected ways, be hard to debug and fail. Chrome protects the content it hosts from this complexity. Interacting with the layer underneath you is part of your job of hosting things on top of you.

▲

tosti 3 days ago | parent [-]

Those are just drivers to stuff that runs its own cpu and interfaces over some kind of serial port. Printers are a well known example of this. Also intel wireless nics with their firmware blobs.

Not are drivers are like that. For instance, drivers/input/serio/ps2-gpio.c is all about timing the right signals.

▲

charcircuit 3 days ago | parent [-]

You are missing the point. The kernel is still abstracting over those GPIO timings so programs don't need to know the timings themselves. This is the benefit of using a platform. These low level things get abstracted away from what you have to do.

	▲	tosti 3 days ago \| parent [-]
		Oh, I see. You're piecing together the layers much like a cake. The way I see it, everything is tied together as some kind of flow chart where different elements have different jobs. Linux is quite a small part of the system when compared to Google Chrome. Even if you were to invert the cake, as a whole it still wouldn't make sense to me to see it that way. Hardware tends to have more distinct layering than the lalala-land of software where pretty much anything goes.