5 ms·

I'd argue that implementing a USB driver would probably be far more educational, in a practical sense, than implementing a kernel. The number of students who wi

I'd argue that implementing a USB driver would probably be far more educational, in a practical sense, than implementing a kernel. The number of students who will go on to work on core kernels is vanishingly small, but driver work is never going to end. 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.

toast0 5y ago
It's not just a USB driver though. You've got to support PCI (or something) to find the USB controller, then you've got to fiddle with that, then you have to discover the devices, then you have to interface with them. 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).
- userbinator 5y ago
  You've got to support PCI (or something) to find the USB controller 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.
  - toast0 5y ago
    Oh sure, PCI isn't too bad, but it's way more work than inb(0x60) or inb(0x3f8). (although to be fair, you probably want to setup an interrupt, which is real work)
glangdale 5y ago
No. Driver work is painful but it mostly teaches you about the h/w in question; you don't learn deep principles from a lot of it. You just grind away, spec in hand, until stuff works. A lot of this winds up being "one damn thing after another". There's a good deal of craft to it, and I don't mean to deprecate it, but it's not broadly applicable. 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.
- deleted 5y ago
  [deleted]
- naasking 5y ago
  > No. Driver work is painful but it mostly teaches you about the h/w in question; you don't learn deep principles from a lot of it. You just grind away, spec in hand, until stuff works. A lot of this winds up being "one damn thing after another". There's a good deal of craft to it, and I don't mean to deprecate it, but it's not broadly applicable. 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.
  - simiones 5y ago
    Sure, but you're not learning anything per se - perhaps some discipline. To some approximation, any two decently competent programmers will take similar amounts of time writing a device driver for a complex novel device regardless of previous experience - the vast majority of the job is in simply going through the spec.
    - naasking 5y ago
      I think ingraining the right discipline might be the hardest part of becoming an effective software engineer. 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.
      - simiones 5y ago
        > I think ingraining the right discipline might be the hardest part of becoming an effective software engineer. 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.
Ericson2314 5y ago
I suppose it would be useful if it taught students how much this industry is hare rather than tortoise nonsense where the interfaces are sheer accidents, and the implementations are mad-dash to keep up. http://langsec.org/ 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.

toast0 5y ago

It's not just a USB driver though. You've got to support PCI (or something) to find the USB controller, then you've got to fiddle with that, then you have to discover the devices, then you have to interface with them. 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).

userbinator 5y ago
You've got to support PCI (or something) to find the USB controller 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.
- toast0 5y ago
  Oh sure, PCI isn't too bad, but it's way more work than inb(0x60) or inb(0x3f8). (although to be fair, you probably want to setup an interrupt, which is real work)

glangdale 5y ago

No. Driver work is painful but it mostly teaches you about the h/w in question; you don't learn deep principles from a lot of it. You just grind away, spec in hand, until stuff works. A lot of this winds up being "one damn thing after another". There's a good deal of craft to it, and I don't mean to deprecate it, but it's not broadly applicable. 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.

deleted 5y ago
[deleted]
naasking 5y ago
> No. Driver work is painful but it mostly teaches you about the h/w in question; you don't learn deep principles from a lot of it. You just grind away, spec in hand, until stuff works. A lot of this winds up being "one damn thing after another". There's a good deal of craft to it, and I don't mean to deprecate it, but it's not broadly applicable. 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.
- simiones 5y ago
  Sure, but you're not learning anything per se - perhaps some discipline. To some approximation, any two decently competent programmers will take similar amounts of time writing a device driver for a complex novel device regardless of previous experience - the vast majority of the job is in simply going through the spec.
  - naasking 5y ago
    I think ingraining the right discipline might be the hardest part of becoming an effective software engineer. 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.
    - simiones 5y ago
      > I think ingraining the right discipline might be the hardest part of becoming an effective software engineer. 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.

Ericson2314 5y ago

I suppose it would be useful if it taught students how much this industry is hare rather than tortoise nonsense where the interfaces are sheer accidents, and the implementations are mad-dash to keep up. http://langsec.org/ 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.