3 ms·

I have never run into a problem that I thought needed to be solved in the kernel. What kinds of things have you wanted to change?

the_only_law 6y ago
Conversely every problem I’ve run into in a kernel that I could potentially solve requires me to be an expert in 1-3 things outside of the kernel.
marcosdumay 6y ago
The first time I went into it was to write a driver for a device in my undergrad. After that I've changed a driver here or there (never anything worth merging), and needed the documentation of the sound systems. It's not an easy thing, by any means. Just locating where you have to touch on the source tree is a problem that will lead you to plenty of books or sites. But don't try reading those before you have a problem to solve, you will lose time and drown in information. (By the way, I am assuming you know how syscalls work. If you don't, go study that before you start anything.)
cgh 6y ago
In my case, which is probably typical, there was a bug in a device driver for some obscure thing we were using where I worked. So I had to dive into the world of kernel modules and fix it. I think a lot of kernel knowledge and development is commercially-driven, in this sense.
sdlion 6y ago
Once I found myself reading about device module programming since the common USB-Serial device module (I forgot its name, cdc something) wasn't properly working for a Chinese multiserial port chip inside a GSM cluster modem (one USB device to multiple serial ports). I was attempting to hack away a simple example but I found the USB-Serial (more) generic driver intended for "test only" and... it just worked. Another reason for reading about IO calls, schedulers, etc? That "I'm still writing data into your USB flash drive even when the GUI says it finished 5 minutes ago" that I hate so much.
bloaf 6y ago
I learned 90% of the things I know about operating systems by solving problems I myself caused.
sebcat 6y ago
Apart from Linux hw support for things at work, I implemented a fairly simple pseudo-device for establishing TCP connections from a process in capability mode on FreeBSD. The device driver has support for a denylist to disallow connections to specific IP ranges. It has multiple syscalls wrapped into one ioctl, and sockets opened from the device always had TCP_NODELAY, O_CLOEXEC and SOCK_NONBLOCK set. Worked pretty well for its intended use case. https://github.com/sebcat/yans/blob/master/drivers/freebsd/tcpsrc/tcpsrc.4.txt https://github.com/sebcat/yans/blob/master/drivers/freebsd/t... https://github.com/sebcat/yans/blob/master/drivers/freebsd/tcpsrc/tcpsrc.c https://github.com/sebcat/yans/blob/master/drivers/freebsd/t...

the_only_law 6y ago

Conversely every problem I’ve run into in a kernel that I could potentially solve requires me to be an expert in 1-3 things outside of the kernel.

marcosdumay 6y ago

The first time I went into it was to write a driver for a device in my undergrad. After that I've changed a driver here or there (never anything worth merging), and needed the documentation of the sound systems. It's not an easy thing, by any means. Just locating where you have to touch on the source tree is a problem that will lead you to plenty of books or sites. But don't try reading those before you have a problem to solve, you will lose time and drown in information. (By the way, I am assuming you know how syscalls work. If you don't, go study that before you start anything.)

cgh 6y ago

In my case, which is probably typical, there was a bug in a device driver for some obscure thing we were using where I worked. So I had to dive into the world of kernel modules and fix it. I think a lot of kernel knowledge and development is commercially-driven, in this sense.

sdlion 6y ago

Once I found myself reading about device module programming since the common USB-Serial device module (I forgot its name, cdc something) wasn't properly working for a Chinese multiserial port chip inside a GSM cluster modem (one USB device to multiple serial ports). I was attempting to hack away a simple example but I found the USB-Serial (more) generic driver intended for "test only" and... it just worked. Another reason for reading about IO calls, schedulers, etc? That "I'm still writing data into your USB flash drive even when the GUI says it finished 5 minutes ago" that I hate so much.

bloaf 6y ago

I learned 90% of the things I know about operating systems by solving problems I myself caused.

sebcat 6y ago

Apart from Linux hw support for things at work, I implemented a fairly simple pseudo-device for establishing TCP connections from a process in capability mode on FreeBSD. The device driver has support for a denylist to disallow connections to specific IP ranges. It has multiple syscalls wrapped into one ioctl, and sockets opened from the device always had TCP_NODELAY, O_CLOEXEC and SOCK_NONBLOCK set. Worked pretty well for its intended use case. https://github.com/sebcat/yans/blob/master/drivers/freebsd/tcpsrc/tcpsrc.4.txt https://github.com/sebcat/yans/blob/master/drivers/freebsd/t... https://github.com/sebcat/yans/blob/master/drivers/freebsd/tcpsrc/tcpsrc.c https://github.com/sebcat/yans/blob/master/drivers/freebsd/t...