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.
... ten years ago, interesting exercise for the teachers, not sure the students liked it though except for the 1% ubergeeks.
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!
You too can modify the kernel with a module that has only been tried on one computer with only the bit of functionality you want.
In kernel space, no one can hear you scream.
If you are going to do this, seriously have your code reviewed by all the available static analyzers you can get your hands on. Double check all your buffer lengths with a calculator. Read a book on C security vulnerabilities.
In a kernel module, you know small C coding defects can catapult into serious problems because the kernel will execute your code with superuser authority.
you are 100% required to send all your code to linus, even your test builds
Searched TFA for "Hello World" ... left satisfied.
your sense of humor is broken
Not really.
Maybe this is one way to indoctrinate next decade's "We work for free and like it dammit!" generation?
I sent it Pi and the universe imploded. Fortunately we had recent back-ups. Though the ones from after Jeb Bush* became president went *ahem* mysteriously missing.
*Replace with Hillary Clinton if you're on the other team.
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.
I've heard of people hacking into a computer system or a network, but not the kernel. I guess malware can hack into the kernel in order to take over the computer system. I learned something new.
I want to drive mouse and keyboard directly from the user space (with admin privileges if needed). I.e. bypassing qt, x windows, so that from the other application it will be indistinguishable from user's input (almost). The question is where do I begin?
PS: Nothing criminal, just software automation.
Why has this article from 15 years ago just appeared? Is it another beta bug?
When I looked through the code, I initially cringed at the use of GOTOs, not knowing that the Linux kernel uses them extensively.
Here's a mailing list thread that explains the rationale:
http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/
This item hit reddit earlier, so I'll repeat my advice.
It might be easier to begin with a kernel module that is useful to you, and either work with the developer or find a module where the developer has lost interest instead.
I worked on two kernel modules, one called oplbeep and the other was totem. Both very simple things that required porting when interfaces changed. Today I work on the vmware modules which are always requiring tweaking (at least unless you upgrade to the latest version of VMWare more regularly) but I do that just to get my work done.
From the tutorial:
----
static struct buffer *buffer_alloc(unsigned long size)
{
struct buffer *buf;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (unlikely(!buf))
goto out;
----
I haven't seen a tutorial written where "goto" was recommended...ever. When I was taught C back in the late 20th century, we weren't taught how to use goto or when. Now that I'm older and wiser, the instruction has its place -- especially in code where performance is paramount -- but it can also be less confusing than other control structures in the right situation. (I'm still uncomfortable using it myself.)
Any wise old vets want to chime in about when to use "goto" and when not to?
-- Political fascism requires a Fuhrer.
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.
... any competent Unix admin could write a device driver. Now a days they barely know the grep.
-- Thou hast strayed far from the path of the Avatar.
This is a repeat article that was on slashwhore about 6-8 years ago. Nothing new with this crap.
You're fired!
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.
When will people give up this love affair with the systemd/NetworkManager/udev/automagic crap? What makes Linux kickass is how NOT Windows-like it is.
I want to delete my account but Slashdot doesn't allow it.
To be honest - I expected the example to be the programmer's equivalent of a guitarist playing Stairway to Heaven. I'm actually disappointed the example wasn't a kernel module to print "Hello World"! :)
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 think not
I'm going to write a kernel module called /dev/registryd that implements a registry because doing string handling in the kernel is a good thing.
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).
You might find The Linux Documentation Project handy. You don't need to know anything about kernel internals to use /dev/input/mice or any of the other devices represented in the /dev filesystem, though. All of the hardware devices in the system can be read and written from /dev , which also includes some pseudo devices such as /dev/random and /dev/null . See:
http://www.tldp.org/LDP/Linux-...
In fact, I'm a full time programmer and sysadmin using Linux exclusively, and I've had exactly ONE case where I needed to look at kernel code. That's my one credit in the kernel changelog.
Aside from the hardware devices in /dev, most of the rest of the kernel is accessible from userspace via the /proc virtual filesystem. From there you can read or set all of the kernel parameters, get information about processes such as which fils they have open, etc. See:
http://www.tldp.org/LDP/Linux-...
If you ever did need to program for the kernel itself, you do so via a module:
http://www.tldp.org/LDP/lkmpg/...
My one credit in the kernel changelog and my one experience with kernel internals, was illustrative of something I've experienced before. I was having a problem with my storage crashing. I was using (abusing?) LVM snapshots, so after following doing what troubleshooting I could, I posted on the LVM mailing list. The LVM maintainer, who is the world's #1 expert on Linux LVM, has me check a couple of things and determined that the problem was likely in the raid module. He suggested I contact the raid devel list. The raid maintainer, who is the #1 expert on Linux raid, looked at it and came up with a fix to the code, which he asked me to try. That worked. I think it's so very cool that the two top experts in the world were so accessible to help me. It didn't cost me a dime. Try that with Windows - try getting the head of Microsoft's storage system programming team to personally assist you. I've found that after I read the documentation such as the appropriate page on tldp.org, the very best of the best Linux developers are always there to help me as long as I follow the advice ESR laid out in http://bettercgi.com/gpl/smart... . Some parts of that document are a bit tongue-in-cheek, or politically incorrect, but it sure does lay out exactly how to get help from very top people.
If you think your example was more readable than the parent, I don't think you're entirely clear on what the word "readable" actually means.
Go home = Very Readable
Go to the Store = Readable
Go to 713 Bond Street = Readable
goto label = Readable
void thing() { a && b && c; } = NOT READABLE!
The idea behind what very experienced programmers call "readability" is to reduce the highly domain-specific knowledge that the reader must study before comprehending your code. The more expertise required in a specific language's structures and idioms, the less readable the code is. Your code may be the greatest thing ever, but frankly its readability sucks.
Over the last 40 years I've frequently encountered code in languages I'd never seen before that was perfectly understandable, because the programmer wrote it with human understanding in mind rather than assuming that humans would spend hours studying abstruse syntactica before reading it.
Elegance in programming is hard. You have to balance the needs of the task, the engine, the user, and the maintenance programmer. Readability is sometimes not achievable without commentry, but truly elegant code is readable.
An example of coding for readability is to be explicit about order of operations; don't make the reader have to look up precedence of operators in your chosen language, use unnecessary parentheses instead... the compiler will not care and the code will not be less efficient, and you'll reduce opportunities for future human errors.