https://news.ycombinator.com/item?id=17692499

That said, BIOSes can also emulate PS/2 with USB (no doubt via SMM). This is usually a setting called "legacy keyboard/mouse support".

[1] The notable exception being Apple. Think Different. https://news.ycombinator.com/item?id=12924051

That used to be true, but the PS/2 is so much slower (lower frequency) that by the time a package containing the mouse or keyboard info is finished transmitting the usb port started and finished a poll

Yes, it’s hard to do research if you start at “let’s design a kernel from scratch,” but you’d never need to do that. You can just hack Linux or a bsd, or even use something like bpf to extend it.

The thing that annoyed me about 410 is that when I switched to Linux I realized that pusha/popa didn’t matter at all. It was a good course for writing reentrant C and learning the very basics of hardware, but the really hard stuff is in the weird dynamics of memory management on NUMA systems and work conserving io, which you can’t get anywhere near if you are starting from scratch.

So you wind up with a research operating system that has finger-painting graphics, can't talk to modern SSDs or networks cards... or you somehow conjure up the resources to build an enormous number of drivers.

If you "hack Linux or a bsd" - or even more timidly - use ebpf - the constraints of what you build are going to result in you basically building "more UNIX stuff". This isn't bad research, but the sheer mass of constraints you're taking on if you accept all the design tradeoffs of Linux/bsd/eBPF/whatever means you're certainly not doing the sort of OS research that the original author talked about.

Why not? Linux has plenty of core design flaws that can't be solved without starting from scratch.

For the complete USB stack, that's very likely. However, for minimal code needed to read keys from keyboard USB shouldn't be that bad.

These students only need USB 1.1. They don't need to support bulk transfers (USB protocol has 2 distinct transports, one low latency another one high throughput). They don't need to support USB hubs between computer and the keyboard. The only device type they need is HID.

USB consortium wouldn't allow to call that protocol USB due to the missing features, but it's good enough for education purposes.

BTW, USB specifies a small subset of HID interface called “boot interface”. It’s normally consumed by UEFI firmware who needs mouse and keyboard for the setup GUI which runs before OS launches. The subset only supports basic keyboards and mice.

I think for the USB in that OS, a C API with intentionally very narrow scope would be OK for the job.

The main reason why the real-life code is so complex is that scope being very wide. We have USB 2 and 3, mass storage, two-way audio, cameras and GPUs, hubs and composite devices, numerous wireless protocols on top, OTG, power delivery, power saving features, and more.

If we were talking about a serious project there are a lot of best practices that should be rarely (and then only carefully) questioned, but for something intended to be thrown away at the end of the semester challenging best practices is a great way to learn.

That said, PS/2 is a simplifying assumption as well.

"Hardware" (read: device drivers) is not notably complicated IMO.

That's not to say they're simple, but driving devices from a software point of view is pretty similar to interacting with other software. You read the spec (APIs), write code to set up data structures or registers a certain way, parse responses, etc.

Writing a modern full fledged USB stack is very complex, but would not be more complex than writing a modern full TCP/IP stack for example.

A lot of device programming models have gotten simpler too. Device drivers used to be notorious deep voodoo magic e.g., in cases of the IDE disk driver, but that was not really "complexity" of the software logic so much as hundreds of special cases and deviations from standards or odd behavior in all manner of IDE controllers and devices. To the point where the real wizards were the ones who had access to internal data sheets, errata, or reverse engineered firmware from these devices, or otherwise spent countless hours poking at things and reconstructing quirks for themselves, probably bricking a lot of silicon and spinning rust in the process.

But systems and devices are now getting to the point where things don't work that way anymore, silicon power is so cheap and firmware is on everything. The NVMe device for example sets up pretty simple packet-type command queues and sends requests and receives responses for operations - query device information, perform a read or write, etc). It's not quite that simple, there are some quirks and details, but it's quite a lot like writing a client for a server (HTTP, perhaps). I think other device interfaces will evolve toward cleaner simpler models like this too.

One exception to this is GPUs of course. The other thing is with moore's law continuing to slow down there will be increased incentive to move more processing out to devices. It's long been happening with high end network devices, but with technologies like CXL.cache coming soon, I would expect that trend to keep ramping up and come to other accelerators (crypto, AI, even disk).

So.. it's a mix. Things are definitely getting more complex, but AFAIKS the complexity of interacting with hardware is not increasing at a much greater rate than the complexity of interacting with other software. And, as always this complexity is made possible by abstractions and layers and interfaces. It's not clearly exceeding our ability to cope with it.

I said the software interfaces to them have not exploded in complexity, i.e., specifically refuting the suggestion that we don't "have the resources to cope with the monstrous complexity of hardware now", from the point of view of driving them with software. You utterly failed to refute anything that I actually wrote, but after your tantrum is over feel free to have an attempt.

And I work at the line and on both sides of it logic, architecture, and software, so don't bother with the vapid appeals to authority.

Utter rubbish. And he goes on to talk about programming for an embedded SoC, etc. Hah. Some of the most utterly wretched code, vhdl, and development practices I've ever had the displeasure of being acquainted with have been in embedded devices, devices, device driers, firmware, etc.

And first level interrupt handlers? He's saying that like it takes some genius to do it, or the process of doing it confers some deep understanding on the writer. It doesn't. It's not particularly complex, outside buggy or stupid architecture but even that's just grinding work.

And the there is some horrific buggy crappy interrupt handler code around and I can say that because I've written some. And it sounds like you may well have too, if your interactions with David Miller relating to the the performance of Sun OS system calls is anything to go by.

Arguably it's more valuable to understand how the C environment (stack, etc) is set up and how to wrangle the toolchain into emiting code at particular locations and such. But you can get all that many other ways. And even then, I don't actually agree that you need to know the minutiae of those details in this day and age which is a great thing. This is not where most of the interesting work is happening, like it or not.

This kind of elitist gatekeeping attitude is just sad. It reeks of the has-been (or maybe never-was) mindset. I would just as well trust code written by someone who deeply understands what they do writing a word processor or video game or distributed database, than someone who has hacked out an interrupt entry vector. And the sad fact is that being an OS developer does not require or confer a deep understanding of how to get the most out of hardware, understanding caches or multiprocessing or branch predictors or performant scalable data structures and synchronization techniques. No more than writing a web server prevents a person from understanding all those things deeply.

That class bordered on legendary. Awesome that you got to TA it. I still have an irrational fondness for AFS.

I believe that the course number changed at some point - or some shallow aspect of the course was set to change - and a bunch of industry people called the university to express concern. It is/was (I can't speak for the current iteration of the course, although I have no indication that quality has slipper or anything) truly transformative.

I offered to run a 'franchise' of the course at the University of Sydney a while back and was informed that anything quite that transformative wasn't really an option; our job was at least in part to pass engineering students who didn't care that much about computing.

Thats very disappointing. You might have more luck joining the University of New South Wales OS team. (For context, UNSW is a local rival of USYD).

When I was a student there, the OS course was legendary. I only did the "basic" OS course. Our assignments led us to implement a bunch of syscalls for handling file IO, and write a page fault handler for a toy operating system. I'm not sure what they do in the advanced OS course - but it has a reputation for a reason. And it looks like[1] its still run by Gernot Heiser, who's a legend. He's the brain behind SeL4 - which is the world's first (and only?) formally verified OS kernel.

I'm kicking myself for not doing his advanced OS course while I was a student.

[1] http://www.cse.unsw.edu.au/~cs9242/current/

Plus, if we ever are to transition to the world of microkernels (something that OS researchers have been pushing for decades now), we're gonna need a massive amount of people writing drivers just to get us to the point where things are barely functional.

Conversely, the work they did in kernels has a huge amount of transfer to thinking about concurrency, which is truly valuable - and deep. It also meant that they acquired a far less magical idea of where things like processes and threads come from, having actually built the mechanisms to make them happen (you build a thread library in a warm-up project).

As for microkernels - they often punt a lot of the hard concurrency stuff up to user space servers, which will wind up needing exactly the kind of concurrency that the students learned to build.

I agree you don't learn deep principles from it, but I disagree that it's not broadly applicable based on your description. Grinding away with spec in hand, "one damn thing after another" sounds exactly like most programming people are likely to encounter in their career.

Also, this course's OS kernel presumably also has a spec, and implementing such a kernel is also "simply going through the spec".

I think the point you're trying to make is that the contents of the spec have be relevant to an operating systems course, and most hardware specs are maybe only tangentially related to the kind of information you have to teach. I'm not sure that's fully true either though, because isolation and safety are core OS properties, eg. DMA has all kinds of security implications. Maybe not stuff for a beginner OS course, but hardware interfacing is critical.

Sure, but that's not the business of a university course to teach.

> Also, this course's OS kernel presumably also has a spec, and implementing such a kernel is also "simply going through the spec".

Per some of the other discussions, this doesn't seem to be the case (i.e. the spec that was offered to students seems to have been quite open ended), as people mention that a huge challenge as a TA was in adapting to the large diversity of approaches that students were trying.

There is also a huge difference between a spec that says "the task scheduler must accept tasks in this format and ensure they are scheduled fairly with an O(n) algorithm" and a spec that says "to enable PVM set bits 1 and 3 in register 7; to issue a new read cycle clear all bits in register 21". Device drivers deal mostly with the latter, unless you move to extremely complex devices like video card drivers, that are probably way more out of scope than a simplistic kernel.

http://langsec.org/

But what you propose is preprofesional drival. It's bad enough that education is subsidized for employers already, we don't need to stoop to them further.

Reading from a keyboard is much simpler. Probably makes more sense to run the computer headless with a serial terminal and make the students poke at a UART. PC standard UARTs are pretty easy, and I think it's easier to find a motherboard with a COM1 header than a PS/2 port (at least my latest hardware matches that description).

PCI is nothing in comparison to the complexity of USB, especially since the BIOS will usually have set up the I/O ranges for the devices already. It's literally a few dozen bytes of machine code to scan the PCI(e) bus for the device you want.