Become a Linux Kernel Hacker and Write Your Own Module 143
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."
Oh no! (Score:5, Funny)
just because (Score:5, Funny)
you are 100% required to send all your code to linus, even your test builds
Re: (Score:3)
Re: (Score:1)
Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?
Allways sounded like a hacking invitation to me.
Re: (Score:3, Funny)
No it was simply a joke Admiral Aspergers.
Re: (Score:1)
Will this proposed kernel module auto-genrate Edward Snowden stories for the Slashdot frontpage, with a POST through the kHTTPd?
Will these stories swap links with OTHER stories on the Slashdot frontpage?
What about Firehose?
Re: (Score:2)
libsnowden is on hold because the author was detained by the NSA.
Re: (Score:2)
libsnowden is on hold because the author was detained by the NSA.
I think they just want to loosen his algorithm and get him to drop his entropy.
Re: (Score:2)
Re: (Score:2)
where does Major Pain fit into the picture?
He's in another chain of command, he reports to General Mayhem.
Re: (Score:3)
Re: (Score:1)
Aided and abetted by Private Parts, Corporal Punishment and Sergeant Rock.
call for warranty service (Score:2, Funny)
your sense of humor is broken
Re: (Score:2)
And you actually have to share it only with the person you are giving the binary to.
Re: (Score:2)
If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.
You sort of proved the GP's point. Only if you choose to use written offer must the offer be good for any third party. If, instead, one distributes binaries with source, there is no obligation to third parties as they should have received source from their distributor.
Re: (Score:3)
You seem to have not italicized the important portion, even though you cut and pasted it into your post! Here I will do it for you:
If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies
Re: (Score:2)
Probably my post was to long to understand for the AC.
Re: (Score:2)
Take it a badge of honour.
Re: (Score:3)
Re: (Score:1)
Hopefully your question was "why is enlightenment so horrible after all these years?"
Re: (Score:3)
Seriously though, I could write several thousand words on why I love Enlightenment. I've been using Linux since 1996 and right now I am running the Bodhi beta and it's the best experience I've ever had with a DE. Keep in mind, development stalled for over a decade and only recently restarted. Enlightenment is now being developed at breakneck pace and they have some really cool stuff going on. Although I personally can't imagine going with anything less,
Very true... (Score:5, Interesting)
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.
Re: (Score:2)
As to the "start off easy" sentiment, I would highly recommend Project Euler: http://projecteuler.net/proble... [projecteuler.net] fun little programming exercises, and can really be done in any language.
Re: (Score:3)
A Project Euler kernel module would be an interesting way to solve some of those...
Re: (Score:3)
Re: (Score:1)
That was my point when I designed this course, I'm not sure I would have the energy and the will to do that again, and I'm only 35.
Give me another ten years and I'll teach VB...
Re: (Score:2)
Give me another ten years and I'll teach VB...
And in 20 more you'll be teaching macros in Filemaker. But I've heard that the lobotomy required for either skillset is rather painless.
Re: (Score:2)
Are you me from 2004?
Ten years ago I taught my sysadmin students how to write kernel modules in Linux (on their LFS systems I had them build); these days I make a living coding in C#...
Also, in 2004 I was 35...
Umm (Score:5, Insightful)
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.
Re: (Score:3)
Some of us build hardware and need to write device drivers.
Cutting through the cruft is exceedingly useful to those of us that want to get the device to work.
Re: (Score:1)
"Fleshlight app" lolol. Did you mean to do that?
Re: (Score:2)
"Fleshlight app" lolol. Did you mean to do that?
Now that's an Android app that would give iOS a run for its money.
Re: (Score:2)
Re: (Score:3)
I've developed Windows drivers before and can say that while yes, it is just plain C or a subset of C++, the APIs are entirely new and come with various curveballs user-mode devs will not have ever dealt with like keeping track of what IRQ level you're at.
A simple driver is... well, fairly simple. Once you try to do anything interesting though, there's a lot to learn before you can be useful. I'm curious if Linux is any different.
Re: (Score:3)
The nice thing is, unless you are doing something totally off the wall, there is a good chance that there is already a module out there that does something similar to what you want to do and the open source love is revealed to you. This applies to many other open-source OSs as well, of course.
Try this with windows and there's a good chance you'll find some incomplete example code from three API revisions ago that won't even compile with the latest libraries (BTDT)
Re: (Score:2)
Try this with windows and there's a good chance you'll find some incomplete example code from three API revisions ago that won't even compile with the latest libraries (BTDT)
Uhhhhh.... for the most part, the kernel API in Windows has been remarkably stable. I have an *extremely* non-trivial Windows driver that works from NT all the way through Win 8. The only major disruption in the 10+ years between NT4 and Vista was the TDI client debacle where they deprecated TDI and there were some workarounds that needed to be implemented to run on the new kernel.
That. Was. All.
I'm not a Linux kernel dev (though have lots of user-mode Linux/Unix experience), but my understanding
Re: (Score:3)
I'm not a Linux kernel dev (though have lots of user-mode Linux/Unix experience), but my understanding of that world is "we'll change anything and everything if and whenever we feel like it, and it's up to the rest of the world to keep up with those changes". So your example, ironically, would apply much more to a Linux driver sample than it would a Windows driver sample.
Linux will change their ABI if necesary, or interal APIs, but not external APIs.
Re: (Score:2)
Why was your driver maintained out-of-tree?
Re: (Score:2)
But not every driver gets included into the kernel. I wanted to use an open source ISDN driver and it was broken because some yahoo had decided that the kernel logging macros all needed to be renamed.
I did kernel development back before Linus even started on Linux and I avoid Linux internals like the plague because they're in a constant state of flux.
Re: (Score:2)
That's probably a feature not a defect if it discourages people from writing kernel code which doesn't need to be kernel code (for example drivers for USB devices).
Re: (Score:2)
I think my specific example was VFW. I was several hours into trying to understand some of the inner workings before finding out they've moved to some new flavor of the week. I threw in the towel at that point as I was only monkeying around with an idea.
Re: (Score:2)
In my experience the concurrency will get you but it's also the lack of memory protection that will drive you nuts. The Linux kernel has everything running in the same address space so a bug in some dippy USB driver can crash the whole system. And that is why you shouldn't let n00bs write kernel code.
Re: (Score:2)
This is why USB drivers should be in userspace (libusb).
Re: (Score:3)
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
Don't be silly.
The goal is to get a nifty new string manipulation API implemented in kernel space. Imagine how slick it would be to use (error checking omitted for brevity):
char* buf; FILE* fp = fopen("/dev/strcat", "r+");
fwrite(string1, string1_length, 1, fp);
fwrite(string2, string2_length, 1, fp);
fflush(fp);
buf = malloc(string1_length + string2_length);
fread(buf, string1_length + string2_length, fp);
fclose(fp);
I mean, how awesome is that? Only 8 lines of code to concatenate two strings! It
Re: (Score:2)
C developer: already a minority in the umbrella of 'programmers' these days
- I write in Java because I have to.
- I write in PHP because I choose to.
- I write in C because I can
(originally was Windows/Mac/Linux)
just remember ... (Score:5, Funny)
In kernel space, no one can hear you scream.
Re: (Score:1)
In kernel space, no one can hear you scream.
Not until you write your own scream driver.
Re: (Score:3)
"I have no dev device, and I must scream"
Re:just remember ... (Score:4, Insightful)
There is always the ability to panic.
Re: (Score:2)
Yeah but if you get mad and start throwing things you can end all of existence. Some say the universe would collapse and reboot but sounds like hocus-pocus to me!
Well (Score:2)
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.
Stop telling me what to do! I don't want to! (Score:3)
Become a Linux Kernel Hacker and Write Your Own Module
I don't want to. You do it. sudo you do it.
Re: (Score:1)
You only sudo do that if you have only dollar no hash. You need to exchange the dollar for #. Then smoke the prompt while entering you command into the wonder buffer. Then see how magically the penguin box obeys even your dd-if=/dev/zero-of=/dev/sda-iest wishes.
sudo should be called SINU - sudo is not unix. Not evrey distro dealer can offer you rial pure sudo. Only use pure sudo! {Hard,Soft}links can harm you health!
To get really high even hash (#) is not enough, your'e really need to enter your kernel spac
Re: (Score:2)
I don't want to. You do it. sudo you do it.
Exactly. Why would I do anything when we have the open source community that will do it for me?
Re: (Score:2)
My advice (Score:2)
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 reg
Re: (Score:2)
Starting with a dead simple module like this is correct.
First Tutorial I've seen with Goto... (Score:2)
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
Re: (Score:1)
The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done. If there is no
cleanup needed then just return directly.
The rationale is:
- unconditional statements are easier to understand and follow ;)
- nesting is reduced
- errors by not updating individual exit points when making
modifications are prevented
- saves the compiler work to optimize redundant code away
https://www.kernel.org/doc/Documentation/CodingSty
Re:First Tutorial I've seen with Goto... (Score:4, Informative)
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:
Re: (Score:2)
Or you could decompose it like an actual software engineer, getting readability and testability and avoiding goto into the bargain:
bool a() { ... } ... } ... }
bool b() {
bool c() {
void thing()
{
a && b && c;
}
My C syntax is a bit rusty, but you get the idea. GCC will likely inline them if they are small anyhow, so you probably won't suffer functional call overhead.
GOTO is all about readability. (Score:2)
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
Re: (Score:1)
I like that you had to do a logic inversion to make your point. You are really showing how confusing inverted logic can be. The if-else code equivalent to your goto code is:
// Done - or log error A // Done - or log error B // Done - or log error C ...
...
if (a) {
}
else if (b) {
}
else if (c) {
}
else
{
}
or it could be written more succinctly as:
if( !( a || b || c) ) {
}
Re: (Score:2)
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
Re: (Score:2)
Not claiming to be a wise old vet, but as a general rule of thumb, the ideal way to use it is to emulate control structures from even higher level languages. For example, if in C++ you'd write an error handling behavior in a function as an exception, in C you might goto a common area to cleanup transient memory and gracefully return an error code. Which is exactly what that snippet you've shown is doing.
Writing modules near impossible (Score:4, Interesting)
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.
Hello World ... (Score:1)
Re: (Score:2)
And none of the article is new. There have been examples of simple modules for linux kernels ever since modules were implemented, in print and on the web. What's new about this, except that Slashdot is now an advertiser for blog articles?
In my day... (Score:2)
"Daunting" (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
Well then I guess I'll just have to take your word for it Mister 914043. ;)
Re: (Score:1)
Re: (Score:1)
And mine. There never was a world of "with many eyeballs, all bugs are shallow"
Re: (Score:1)
OpenSSL much?
Re: (Score:2)
and my axe!
Re: (Score:2)
Depends what you mean by "code in C"
I think the vast majority of us at some point have made a C program go "Hello World!" Many more of us have overloaded some operators and learned some other elements of the language.
But there's a world of difference between that, and being a competent C developer. That is something that takes years to learn and quite a bit of work. And while I am sure if I had the time and the yearning to be one I could, I just know I am not.
Re: (Score:1)
Doesn't sound a very good idea to do in C... Sure, you can always #define +, but don't wonder why all of your coworkers will hate you for it.
Re: (Score:2)
LOL... You might want to read my post.
Having taken some programming courses that covered C, I've created a pointer or two and overloaded a few operators, but you really wouldn't want to let me become a developer on any major C based project.
(although that doesn't mean I don't think I COULD be one if I put in the time or effort -- just that familiarity with a language and the ability to write kernel drivers are two very different things)
Re: (Score:2)
And this is why you should keep me away from any C based kernel development ;)
Fuzzy memories of what may or may not be and how to do things. And I'd bet other /.s have similar experiences
Re: (Score:3)
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.
I suggest that most people here are just consumers. They try various distros and use open source code that has been readily made available for them. They rarely look at the code or even make the smallest modifications. Not to even talk about something like writing kernel modules from scratch. On the other hand, I believe that the UNIX command line skills of people here are generally quite good, and thus they can drill quite deep in user space administration, configuration, automation and proper bug reportin
Re: (Score:2)
Example kernel module written in rust, for those interested...
https://github.com/tsgates/rus... [github.com]
I got to the part about udev and closed the window (Score:1)
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.
Re: (Score:1)
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.
screw it i'm gonna put my hosts file in the kernel (Score:4, Insightful)
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!
device driver (Score:3)
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).
Re: (Score:3)
/dev/input [linuxjournal.com]
Also uinput, /dev/input/mice, use the damn API (Score:3)
> 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
Re: (Score:1)
That trick is pretty slick.
As one of what I feel to be a growing breed of Linux users that started off in Ubuntu, and has very very slowly been learning how Linux works internally, all of this is still a bit of black magic. Is there a "From Ubuntu to Linux Hacker" guide out there that briefly and simply explains how the Linux kernel works? All the resources I've found get too deep too quickly.
/dev and /proc. See http://www.tldp.org/, experts (Score:2)
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-... [tldp.org]
In fact, I'm a full time programmer and sysadmin using Linux exclusively, and I've had exactly ONE case where I neede
Re: (Score:2)
Re: (Score:1)
The koblents.com link is an interesting read and using a goto may actually be valid inside an o.s. Having said that, after having written a significant number of tens of thousands of lines of C (most of which was outside the kernel), I still have never used a goto and I don't plan to.
Re: (Score:2)
Re: (Score:1)
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.
. . . Have you never read the JARGON file? :0
http://jargon-file.org/archive... [jargon-file.org]