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.
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.
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.