Slashdot Mirror
Become a Linux Kernel Hacker and Write Your Own Module
M-Saunders (706738) writes "It might sound daunting, but kernel hacking isn't a mysterious black art reserved for the geekiest of programmers. With a bit of background knowledge, anyone with a grounding in C can implement a new kernel module and understand how the kernel works internally. Linux Voice explains how to write a module that creates a new device node, /dev/reverse, that reverses a string when it's written to it. Sure, it's not the most practical example in the world, but it's a good starting point for your own projects, and gives you an insight into how it all fits together."
Just to have Linus publicly cuss me out? No thanks!
...I remember my first meeting with Slackware, it was a Linux distro that provoked any user to learn stuff from scratch, and you HAD to use the command line (bash/shell) to install it if you wanted to use it. This forced me to learn Linux. (At least some of the basics)
It also came with a Kernel compilation system + all the needed libraries and packages, so compiling to your own computer was a few commands and worked right out of the box. And then my curiosity got piqued and this drove me to go into the configuration and find out how I could optimize my kernel to fit my needs. In the beginning it was a lot of trial and error, and it looked real daunting, but after a few tries - it wasn't nearly as scary. Before you knew it, I was coding my first stuff in C++. A lot of fun, actually.
So yeah, by all means - if you guys have the time, the curiosity, do go ahead and code something, but do yourself a favor - start off easy.
What this world is coming to - is for you and me to decide.
Well yes, any C developer (already a minority in the umbrella of 'programmers' these days) can write code for the kernel, but just because one can write software for the kernel doesn't mean they can write anything meaningful to be done in kernel space vs. anywhere else. If you're expecting a slew of new driver hackers reverse engineering chipsets, and implementing better drivers, testing all corner cases (because dev's LOVE testing) I think you're barking up a very small tree, but all the luck to you, becase what's good for Linux is good for me, you, us all.
Bye!
In kernel space, no one can hear you scream.
I feel like any OS course worth a damn should force you to write at least one OS kernel module; and unless your course uses one of the academic OSes, it might as well be on Linux.
you are 100% required to send all your code to linus, even your test builds
your sense of humor is broken
Become a Linux Kernel Hacker and Write Your Own Module
I don't want to. You do it. sudo you do it.
systemd is Roko's Basilisk.
/dev/input
When all you have is a hammer, every problem starts to look like a thumb.
While the article shows a cute little example on how to write a useless module, it does not show anyone how to actually write a serious kernel module. The Linux kernel has never been known for documenting kernel internals, such documentation is scant at best and simply not sufficient to write a module. It is safe to say tha due to the poor practices of Kernel developers who constitently ignore good practice by not Documenting Their Crap, the kernel is an elite club of developers with knowledge that is secret. The practices of the Linux kernel development is just sheer sloppiness, horribly bad practice. They could have easily set up a Wiki and documented the interfaces and their architecture. What we see with the kernel developers is that they do not care about anyone else, not users, and not even outside techies, so why would they care about whether or not an outsider can understand the kernel, just as why would they care if a user can upgrade kernel versions without having all of their device drivers blow up. As anyone well versed in computer science knows, computer code is rarely self documenting, especially the kernel, and trying to reverse document a large software project is an outrageous waste of time and can be enough of a problem that it keeps even seasoned programmers away from the project. A huge piece of undocumented code is just not worth the effort to learn.
Just like any other construct - when it makes the code more clean, clear, correct, and/or optimized. These are tradeoffs.
For instance, let's say you have a function having a deeply nested conditional:
This code might be more simply understood as:
That is all.
You know, I'd like to think there was a time when the majority of Slashdot users could cheerfully take on writing modules for the Linux kernel or *gasp* just code in C.
Happy people make bad consumers.
I got my intro to programming in the mid 1960s with 'the college computer' a PDP-8 that we programmed in Fortran using punched cards. In those days, just getting access to a computer was a pretty big deal, but things were changing, so 'programming paradigms' started appearing, and the first one that I remember was 'structured programming'. This is where I first heard the mantra of 'goto-less' programming. (Before that, the mantra was not to write self-modifying code, which was something you almost had to be writing assembly language code to be able to do, though COBOL had an 'alters' statement as I recall.)
I remember being somewhat startled by the idea of excluding gotos. How could you write non trivial code without any goto statements? I actually thought of it almost as a challenge to figure out how to do so. The opposite of structured code was 'spaghetti code'. Anyway, it's become a conventional bit of wisdom that I suppose is just automatically passed down to each generation of students without anyone ever seriously questioning it, except those who find they really need it sometimes. At some point I started defiantly putting an occasional goto in my code again, but not often.
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
Take that APK! I'm going to put my motherfucking hosts file in the kernel..that's right.. I'm going to have a /dev/hosts
You heard me right! /dev/motherfucking/hosts
True ring 0 baby!
> PS: Nothing criminal, just software automation.
The GUI probably calls function in a library, if not command line binaries. You are normallybetter off using the library directly rather than emulating GUI input from the user.
To fake user input, see uinput. Also, you can capture the events using od tool from the /dev/input/mice and then replay them once you have decoded the sequence.
# cat /dev/input/mice | od -t x1 -w3
0000000 08 02 00
0000003 08 08 00
0000006 08 09 00
0000011 08 07 00
0000014 08 04 00
0000017 08 01 01
0000022 08 00 02
0000025 08 02 02
I once had to write a module for a pc/104 board on an embedded system running kernel 2.4. It had 8 relays that were write-only, there was no way to query a relay for what it's current position was, so I kept track of it myself and made the cached status available by a proc entry.
It wasn't really that hard and I learned a bit more about how the kernel modules got initialized and executed. I wrote a couple of others also, like for the Sensoray Model 518 (which is discontinued now I think).