4 ms·

Kernel engineer. Yeah, I enjoy it. I like operating systems, data structures, security considerations, low level code... so that's a good fit. It shifted my ho

by anyfoo 4y ago

Kernel engineer. Yeah, I enjoy it. I like operating systems, data structures, security considerations, low level code... so that's a good fit. It shifted my hobby projects to get even "lower" level though, which now has a lot of signal processing and electrical engineering, both in the analog (with some RF) and digital (including FPGAs) domain. I am determined to absolutely not let my job creep towards that direction, I want it to stay separate. Fortunately, I'm nowhere near experienced enough for anyone to consider that jump anyway. By now a relatively long time ago, I was privately talking to a former employee of the company I'm now working at about hobby stuff. He said I seem to enjoy the relevant things, so asked for a CV and referred me. I didn't know where he was working at the time, so this was entirely organic, and got me an internship at first.

pipeline_peak 4y ago
How’d you meet the former employee? I’m trying to break out of enterprise .NET into low level stuff. I can’t say kernel engineering is exactly what I want to do, but given I only have a bachelor, it sounds like something I can immerse myself in without the existential dread of enterprise software.
- anyfoo 4y ago
  I met him through a common low-level interest. As said, I didn't even know, nor actually care, what he was working. Our correspondence was purely a hobby project thing, until he asked whether I would be interested in a topic-adjacent internship. If you're dreading enterprise software, kernel engineering is (usually at least) definitely pretty far from that. I would say you have to have a knack for it, since among other things you'll be dealing with problems that, for "higher level" engineering, are usually already solved on some lower layers, and also because debugging is often an exercise in creativity and knowing (and learning, ad-hoc) a meticulous amount of details. Being passionate about that certainly helps. But absolutely try it out for yourself, maybe it's your cup of tea and you just didn't know it yet.
- the_only_law 4y ago
  Getting out of the enterprise world in general seems to be a huge pain.
elteto 4y ago
How do you break into kernel engineering?
- anyfoo 4y ago
  Everyone can do kernel development. Linux and the BSDs guarantee that. To get a kernel engineering job, once you've gathered some experience, you could become an embedded engineer, or e.g. a driver engineer... Modern kernels are vast, there is always opportunity to branch into new areas. If the question is how to learn kernel development, I would say it probably involves reading some books about modern OSes in general as a primer, reading specs (e.g. the reference manual of the CPU; just like other references you fortunately don't have to read all of it to get started), and reading lots of kernel code (that will be true throughout your entire career). The aforementioned OS kernels also contain documentation that really helps getting into specific areas. You can most likely find some good lists. I started long enough ago that I have a hard time recommending any specific resources. It was during a time where there were entirely "unmodern" OSs around, such as MS-DOS or OSs on home computers, so my learning involved some transitioning between OS paradigms, mostly going from simpler to more complex. That would not really apply today. It's also hard to make general recommendations in the first place, because parts of the kernel range from high level, where the jump from userspace programming is not that far, to potentially rather arcane, such as low level memory management or context switching code. From a glance at your comment history, it's very likely that there's some part of the kernel where you can just jump in, and expand as necessary.
  - livueta 4y ago
    This is all great advice. > probably involves reading some books about modern OSes in general as a primer > I started long enough ago that I have a hard time recommending any specific resources. Having gotten into kernel programming in the last decade I'd just like to offer a specific recommendation that really helped me out: https://www.amazon.com/Design-Implementation-FreeBSD-Operating-System-ebook/dp/B00O56CFEE https://www.amazon.com/Design-Implementation-FreeBSD-Operati... I started out literally just reading stuff in the source tree/man(9) (which was informative!) but then my employer gave me a copy of this book, and I found it to be a super-helpful aid in understanding the general organization and motivation of the kernel: what kinds of tasks and problems each component needs to address, how components interact with each other, and the basic building blocks by which these things get done. I found that having a higher-level understanding of the what/why of each bit, covering algorithm/data structure details but probably not the exact code implementation, made grasping the actual kernel code a lot easier. Oh, also: dtrace is a very fun and interactive way of getting a live peek into FreeBSD kernel structures without doing a whole bunch of scary recompilation. You can e.g. start digging around in `curthread->td_proc` on a process you control and you'll discover a whole lot about how the kernel manages processes.

by anyfoo 4y ago

pipeline_peak 4y ago

How’d you meet the former employee? I’m trying to break out of enterprise .NET into low level stuff. I can’t say kernel engineering is exactly what I want to do, but given I only have a bachelor, it sounds like something I can immerse myself in without the existential dread of enterprise software.

anyfoo 4y ago
I met him through a common low-level interest. As said, I didn't even know, nor actually care, what he was working. Our correspondence was purely a hobby project thing, until he asked whether I would be interested in a topic-adjacent internship. If you're dreading enterprise software, kernel engineering is (usually at least) definitely pretty far from that. I would say you have to have a knack for it, since among other things you'll be dealing with problems that, for "higher level" engineering, are usually already solved on some lower layers, and also because debugging is often an exercise in creativity and knowing (and learning, ad-hoc) a meticulous amount of details. Being passionate about that certainly helps. But absolutely try it out for yourself, maybe it's your cup of tea and you just didn't know it yet.
the_only_law 4y ago
Getting out of the enterprise world in general seems to be a huge pain.

elteto 4y ago

How do you break into kernel engineering?

anyfoo 4y ago
Everyone can do kernel development. Linux and the BSDs guarantee that. To get a kernel engineering job, once you've gathered some experience, you could become an embedded engineer, or e.g. a driver engineer... Modern kernels are vast, there is always opportunity to branch into new areas. If the question is how to learn kernel development, I would say it probably involves reading some books about modern OSes in general as a primer, reading specs (e.g. the reference manual of the CPU; just like other references you fortunately don't have to read all of it to get started), and reading lots of kernel code (that will be true throughout your entire career). The aforementioned OS kernels also contain documentation that really helps getting into specific areas. You can most likely find some good lists. I started long enough ago that I have a hard time recommending any specific resources. It was during a time where there were entirely "unmodern" OSs around, such as MS-DOS or OSs on home computers, so my learning involved some transitioning between OS paradigms, mostly going from simpler to more complex. That would not really apply today. It's also hard to make general recommendations in the first place, because parts of the kernel range from high level, where the jump from userspace programming is not that far, to potentially rather arcane, such as low level memory management or context switching code. From a glance at your comment history, it's very likely that there's some part of the kernel where you can just jump in, and expand as necessary.
- livueta 4y ago
  This is all great advice. > probably involves reading some books about modern OSes in general as a primer > I started long enough ago that I have a hard time recommending any specific resources. Having gotten into kernel programming in the last decade I'd just like to offer a specific recommendation that really helped me out: https://www.amazon.com/Design-Implementation-FreeBSD-Operating-System-ebook/dp/B00O56CFEE https://www.amazon.com/Design-Implementation-FreeBSD-Operati... I started out literally just reading stuff in the source tree/man(9) (which was informative!) but then my employer gave me a copy of this book, and I found it to be a super-helpful aid in understanding the general organization and motivation of the kernel: what kinds of tasks and problems each component needs to address, how components interact with each other, and the basic building blocks by which these things get done. I found that having a higher-level understanding of the what/why of each bit, covering algorithm/data structure details but probably not the exact code implementation, made grasping the actual kernel code a lot easier. Oh, also: dtrace is a very fun and interactive way of getting a live peek into FreeBSD kernel structures without doing a whole bunch of scary recompilation. You can e.g. start digging around in `curthread->td_proc` on a process you control and you'll discover a whole lot about how the kernel manages processes.