4 ms·

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 h

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.

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.