Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Become a Linux Kernel Hacker and Write Your Own Module

Soulskill posted about 4 months ago | from the or-else dept.

Programming 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."

cancel ×

143 comments

Sorry! There are no comments related to the filter you selected.

Oh no! (5, Funny)

fizzer06 (1500649) | about 4 months ago | (#47102503)

Just to have Linus publicly cuss me out? No thanks!

just because (5, Funny)

Anonymous Coward | about 4 months ago | (#47102599)

you are 100% required to send all your code to linus, even your test builds

Re:just because (-1)

jcochran (309950) | about 4 months ago | (#47102633)

Typical misconception of GPL. You are required to share any code modifications /IF/ you distribute the modified executable. If your changes are for your use only, feel free to keep 'em to yourself.

Although to be honest, if I had mod points, I would have rated fizzer06's comment as +1 Funny.

Re:just because (3, Funny)

Anonymous Coward | about 4 months ago | (#47102647)

No it was simply a joke Admiral Aspergers.

Re:just because (0)

Jeremiah Cornelius (137) | about 4 months ago | (#47102705)

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:just because (1)

binarylarry (1338699) | about 4 months ago | (#47102797)

libsnowden is on hold because the author was detained by the NSA.

Re:just because (0)

Anonymous Coward | about 4 months ago | (#47102865)

libsnowden is on hold because the author was detained by the NSA.

But /dev/coldfjiord is OK.

Re:just because (1)

Jeremiah Cornelius (137) | about 4 months ago | (#47103187)

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:just because (0)

Anonymous Coward | about 4 months ago | (#47103203)

BTW: NSA fags reading this, wipe the shit off the end of your dicks, before jabbing at the keyboards, OK?

Re:just because (1)

RightwingNutjob (1302813) | about 4 months ago | (#47102893)

Ah! So Captain Obvious finally has someone to report to! It's all falling into place...but where does Major Pain fit into the picture?

Re:just because (1)

stjobe (78285) | about 4 months ago | (#47102939)

where does Major Pain fit into the picture?

He's in another chain of command, he reports to General Mayhem.

Re:just because (0)

Anonymous Coward | about 4 months ago | (#47103085)

Actually General Disarray, who in turn is the lackey of Professor Chaos....

Re:just because (2)

QRDeNameland (873957) | about 4 months ago | (#47104063)

Don't forget about Colonel Panic!! (to bring this back kinda on-topic)

Re:just because (1)

HagraBiscuit (2756527) | about 4 months ago | (#47106755)

Aided and abetted by Private Parts, Corporal Punishment and Sergeant Rock.

Re:just because (0)

Anonymous Coward | about 4 months ago | (#47104037)

You're missing a comma, Admiral Shittygrammar.

call for warranty service (2, Funny)

Anonymous Coward | about 4 months ago | (#47102699)

your sense of humor is broken

Re:just because (-1)

Anonymous Coward | about 4 months ago | (#47102765)

WHY DO YOU REPUBLICANS KEEP TELLING THAT LIE? I also heard Ballmer tell that lie in person about five years ago. Why does your kind claim that the GPL is a virus? We all know that is a lie. Just because you make a change doesn't mean you have to redistribute it no matter how many times you Republicans claim otherwise. You only have to redistribute the source to your changes if you redistribute the change outside of your organization. You are a liar.

Re:just because (0)

Anonymous Coward | about 4 months ago | (#47103447)

Idiot troll post. What a moron.

Re:just because (0)

Anonymous Coward | about 4 months ago | (#47103989)

Dickbreath???

Re:just because (1)

drolli (522659) | about 4 months ago | (#47102817)

And you actually have to share it only with the person you are giving the binary to.

Re:just because (-1)

Anonymous Coward | about 4 months ago | (#47103049)

Wrong.

GPLv2:

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

Re:just because (0)

Anonymous Coward | about 4 months ago | (#47103231)

That language only applies if you don't give the source with the binary. If you give the source to the person to whom you gave the binary, your obligation is done.

Now, if that person gives out the binary, they THEY have to pass along the source or accompany it with a written offer...

Re:just because (-1)

Anonymous Coward | about 4 months ago | (#47103367)

You're simply wrong.

What does “written offer valid for any third party” mean in GPLv2? Does that mean everyone in the world can get the source to any GPL'ed program no matter what? (#WhatDoesWrittenOfferValid)
If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it.

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.

The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.

http://www.gnu.org/licenses/gp... [gnu.org]

Read the italicized portion until it sinks in.

Re:just because (1)

devman (1163205) | about 4 months ago | (#47103523)

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:just because (2)

spitzak (4019) | about 4 months ago | (#47103553)

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 of the source code, along with the written offer.

I think it is your turn to read the italicized portion until it sinks in.

Re:just because (1)

drolli (522659) | about 4 months ago | (#47105869)

Probably my post was to long to understand for the AC.

Re:just because (0)

Anonymous Coward | about 4 months ago | (#47103391)

To quote the FSF:

If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it.

The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.

http://www.gnu.org/licenses/gp... [gnu.org]

Re:just because (-1)

Anonymous Coward | about 4 months ago | (#47102837)

The autism is strong in this one.

Re:just because (2)

craigminah (1885846) | about 4 months ago | (#47104135)

Funny they say programming something to the Linux kernel is "hacking" rather than "programming.' Most likely to draw in the l33t kids who want to haxor something.

Re:just because (1)

xvan (2935999) | about 4 months ago | (#47104625)

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:just because (0)

Anonymous Coward | about 4 months ago | (#47104665)

that term has existed for quite awhile, unrelated to haxing

Re:just because (0)

Anonymous Coward | about 4 months ago | (#47110153)

Funny they say programming something to the Linux kernel is "hacking" rather than "programming.' Most likely to draw in the l33t kids who want to haxor something.

"hacking" got co-opted (similarly to how "gay" refers to persons of homosexual inclination rather than happy people these days. not judging in this comparison, just an example of co-opting). It simply means engineering something in a clever way, the canonical example being a model railway control system being built with phones. There is still a (for lack of a more positive word) stubborn section of the population that refuses to let that term refer to script kiddies, warez/scene types, or other persons who are, to them, "cracking". Google "Hacker Ethic" some time, most results will provide a bit more insight and historical information than I care to get into right now.

Re:Oh no! (1)

TechyImmigrant (175943) | about 4 months ago | (#47102615)

Take it a badge of honour.

Re:Oh no! (2)

wjcofkc (964165) | about 4 months ago | (#47102671)

I've been following the Enlightenment project since its inception. A few months ago I had to hop on their mailing list and ask a question for the first time. Rasterman replied, which itself seemed an honor. Doubly so that he kinda called me an idiot in that round about way he does. It was a good day.

Re:Oh no! (1)

Anonymous Coward | about 4 months ago | (#47102829)

Hopefully your question was "why is enlightenment so horrible after all these years?"

Re:Oh no! (2)

wjcofkc (964165) | about 4 months ago | (#47103027)

It's not horrible, it's............ misunderstood. : P

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, at the end of the day I advise most people to use something else like.... elementary OS. The fact is Enlightenment is simply to complicated for most people to bother with the learning curve.

Re:Oh no! (0)

Anonymous Coward | about 4 months ago | (#47110367)

Enlightenment is a nice WM, but it has one killer problem for me: the difficulty of configuring it. Seriously, there are at least three different ways to get to the same menu, but the menus mostly just repeat themselves. You can find all sorts of options on how to get it to change themes and icons, but I couldn't get it to place certain applications on certain desktops when they are started. The graphics are very pretty, but the theme selection is pretty limited (I've been trying to find a nice repository, but most I go to either don't have working themes, or have long since been shutdown). However, if they're rapidly developing it, I think I'll take another look at it. Maybe something's changed in the last year. Currently, I use the i3 window manager, for its awesome (hehe, pun most certainly intended) tiling capabilities, ease of configuration, and great multimonitor support.

Very true... (4, Interesting)

MindPrison (864299) | about 4 months ago | (#47102547)

...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.

Re:Very true... (1)

by (1706743) (1706744) | about 4 months ago | (#47102911)

Soft spot in my heart for Slack, too -- although I started off with an old RedHat CD I picked up at a garage sale (2.0 kernel series, I think), Slack was the first distro I really started using. Great stuff, though I've now moved on to Debian.

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:Very true... (2)

inasity_rules (1110095) | about 4 months ago | (#47106763)

A Project Euler kernel module would be an interesting way to solve some of those...

Been there done that... (0)

Anonymous Coward | about 4 months ago | (#47102565)

... ten years ago, interesting exercise for the teachers, not sure the students liked it though except for the 1% ubergeeks.

Re:Been there done that... (2)

Verdatum (1257828) | about 4 months ago | (#47102579)

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.

Re:Been there done that... (1)

Anonymous Coward | about 4 months ago | (#47102631)

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:Been there done that... (1)

Mordok-DestroyerOfWo (1000167) | about 4 months ago | (#47102979)

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:Been there done that... (1)

stjobe (78285) | about 4 months ago | (#47102981)

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 (4, Insightful)

ADRA (37398) | about 4 months ago | (#47102567)

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:Umm (2)

TechyImmigrant (175943) | about 4 months ago | (#47102607)

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:Umm (0)

Anonymous Coward | about 4 months ago | (#47102625)

Good kernel developers have a number of options. For example, dealing with Android devices. If one can get the specs for SoC functions, there might be functionality on a tablet or smartphone just waiting to be taken advantage of by someone who can read the details and write a kernel module to take advantage of this.

Disclaimer: More kernel developers and fewer people making yet another fleshlight app on iOS or Android is a good thing. It takes real talent to program on this level due to resource limitations and the fact that one goof, and the bug is a show-stopper.

Re:Umm (1)

koreanbabykilla (305807) | about 4 months ago | (#47102869)

"Fleshlight app" lolol. Did you mean to do that?

Re:Umm (1)

Mordok-DestroyerOfWo (1000167) | about 4 months ago | (#47102987)

"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:Umm (1)

fizzer06 (1500649) | about 4 months ago | (#47103181)

What happened to all of the really good fart apps?

Re:Umm (2)

PhrostyMcByte (589271) | about 4 months ago | (#47102655)

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:Umm (2)

Richy_T (111409) | about 4 months ago | (#47102807)

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:Umm (2)

WalrusSlayer (883300) | about 4 months ago | (#47103227)

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 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.

Re:Umm (2)

hobarrera (2008506) | about 4 months ago | (#47103283)

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:Umm (0)

Anonymous Coward | about 4 months ago | (#47103485)

Linux changes kernel APIs all over the place. It doesn't change user space things and system calls and similar.

I worked for a shop which had a set of high-performance PCIe drivers. Windows WDM-model drivers worked everywhere from NT to Windows 8 without any changes.

The Linux drivers on the other hand, had hundreds of #ifdef's against kernel versions everywhere. It seems that every 3 or 4 versions there was some symbol name change and/or semantic difference related to something critically important like interrupts.

When Linux people say they don't break the interface - they are only referring to user-space stuff. The kernel is all about optimization and forward-thinking. They do not care about backwards compatibility.

Re:Umm (0)

Anonymous Coward | about 4 months ago | (#47104647)

and if you had submitted those for inclusion into the kernel, all those changes would have been done for you by those who proposed the change - even without any ifdef'ery.

Re:Umm (1)

putaro (235078) | about 4 months ago | (#47104927)

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:Umm (1)

Alioth (221270) | about 4 months ago | (#47106279)

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:Umm (1)

shiftless (410350) | about 4 months ago | (#47138209)

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).

Look in the mirror: you are the problem. Stop apologizing for idiocy.

Re:Umm (1)

hobarrera (2008506) | about 3 months ago | (#47205543)

Why was your driver maintained out-of-tree?

Re:Umm (-1)

Anonymous Coward | about 4 months ago | (#47104173)

Someone downmod this Windows $shill frog-hatted faggot; I DISAGREEEEEEEEEEE!!!!!!!!!!!!!!!!!!!!

Re:Umm (1)

Richy_T (111409) | about 4 months ago | (#47111617)

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:Umm (0)

Anonymous Coward | about 4 months ago | (#47102951)

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.

An old rule of thumb: compilers are 10x tricker to write than applications, OS-level code is 10x trickier than that.

I don't know about the compiler factor anymore, since modern GUI programs tend to be pretty complex themselves, but the problem with OS-level code is that concurrency is rampant plus you have to be aware of hardware state.

Re:Umm (1)

putaro (235078) | about 4 months ago | (#47104937)

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:Umm (1)

Alioth (221270) | about 4 months ago | (#47106281)

This is why USB drivers should be in userspace (libusb).

Re:Umm (1)

P Bacon (3557945) | about 4 months ago | (#47102669)

Well, the embedded systems market is due to flourish any minute now. There will likely be many small trees worth barking up. Arch on Rockchip!

Re:Umm (2)

swillden (191260) | about 4 months ago | (#47102953)

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 would even be trivial to include multiple copies of string1 and/or string2 if you wanted!

And since it's implemented in the kernel you know it'll be uber fast and secure.

Re:Umm (1)

hcs_$reboot (1536101) | about 4 months ago | (#47105657)

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)

Yay (0)

Anonymous Coward | about 4 months ago | (#47102573)

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.

just remember ... (5, Funny)

nblender (741424) | about 4 months ago | (#47102575)

In kernel space, no one can hear you scream.

Re:just remember ... (1)

Anonymous Coward | about 4 months ago | (#47102687)

In kernel space, no one can hear you scream.

Not until you write your own scream driver.

Re:just remember ... (2)

iggymanz (596061) | about 4 months ago | (#47102757)

"I have no dev device, and I must scream"

Re:just remember ... (0)

Anonymous Coward | about 4 months ago | (#47102695)

***********
KHAN !
***********

Re:just remember ... (3, Insightful)

mlts (1038732) | about 4 months ago | (#47102849)

There is always the ability to panic.

Re:just remember ... (1)

rabtech (223758) | about 4 months ago | (#47104855)

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!

ATTENTION, like EVERYBODY (0)

Anonymous Coward | about 4 months ago | (#47102591)

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.

Re:ATTENTION, like EVERYBODY (0)

Anonymous Coward | about 4 months ago | (#47102613)

Or don't run your alpha quality modded kernel on a public box?

Hello World! (0)

Anonymous Coward | about 4 months ago | (#47102645)

Searched TFA for "Hello World" ... left satisfied.

1982 all over again and boy am I excited (0)

Anonymous Coward | about 4 months ago | (#47102737)

Not really.

Maybe this is one way to indoctrinate next decade's "We work for free and like it dammit!" generation?

Re:1982 all over again and boy am I excited (0)

Anonymous Coward | about 4 months ago | (#47103111)

Really? I wish to subscribe to your newsletter containing listings of free jobs I can work for free.

Re:1982 all over again and boy am I excited (0)

Anonymous Coward | about 4 months ago | (#47106181)

A lot of open source is done like this.

Well (1)

Richy_T (111409) | about 4 months ago | (#47102777)

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! (2)

wonkey_monkey (2592601) | about 4 months ago | (#47102975)

Become a Linux Kernel Hacker and Write Your Own Module

I don't want to. You do it. sudo you do it.

Re:Stop telling me what to do! I don't want to! (1)

Anonymous Coward | about 4 months ago | (#47103451)

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 space quarters for ring 0 to rulez them all.

Re:Stop telling me what to do! I don't want to! (1)

jones_supa (887896) | about 4 months ago | (#47106199)

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:Stop telling me what to do! I don't want to! (1)

RavenLrD20k (311488) | about 4 months ago | (#47111483)

Research. Learning. Curiosity. World Domination.

hacking (0)

Anonymous Coward | about 4 months ago | (#47102991)

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.

Re:hacking (1)

jones_supa (887896) | about 4 months ago | (#47106211)

So it has come to this.

Re:hacking (1)

Gallefray (2534514) | about 4 months ago | (#47113419)

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]

Good! Now I have questions: (0)

Anonymous Coward | about 4 months ago | (#47103031)

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.

Re:Good! Now I have questions: (2)

Tough Love (215404) | about 4 months ago | (#47103207)

/dev/input [linuxjournal.com]

Also uinput, /dev/input/mice, use the damn API (2)

raymorris (2726007) | about 4 months ago | (#47104615)

> 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

Re:Also uinput, /dev/input/mice, use the damn API (1)

trev.norris (2010080) | about 4 months ago | (#47106981)

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 (1)

raymorris (2726007) | about 4 months ago | (#47107845)

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 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-... [tldp.org]

If you ever did need to program for the kernel itself, you do so via a module:
http://www.tldp.org/LDP/lkmpg/... [tldp.org]

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... [bettercgi.com] . 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.

Uberdupe (0)

Anonymous Coward | about 4 months ago | (#47103043)

Why has this article from 15 years ago just appeared? Is it another beta bug?

GOTOs (0)

Anonymous Coward | about 4 months ago | (#47103055)

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/

Re:GOTOs (1)

tomhath (637240) | about 4 months ago | (#47103461)

Interesting thread. But it would be nice if Linus would tell us what he really thinks...

Re:GOTOs (1)

NikeHerc (694644) | about 4 months ago | (#47104633)

rationale

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.

My advice (1)

jgotts (2785) | about 4 months ago | (#47103075)

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.

Re:My advice (1)

Tough Love (215404) | about 4 months ago | (#47103223)

Starting with a dead simple module like this is correct.

First Tutorial I've seen with Goto... (1)

Prien715 (251944) | about 4 months ago | (#47103309)

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?

Re:First Tutorial I've seen with Goto... (1)

Anonymous Coward | about 4 months ago | (#47103425)

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/CodingStyle

Re:First Tutorial I've seen with Goto... (0)

Anonymous Coward | about 4 months ago | (#47103431)

I'm not old or wise but I do use goto's it's fairly common in kernel code. I've written several drivers in Windows and Linux, and use goto's in plenty of spots, but for a very specific reason, and under a few constraints. The reasons being that there is some staging of setup that is going where you have to do something like:
{ ...
        if(setup1() != SUCCESS)
        {
                goto undo_setup1;
        } // Depends on setup1 success
        if(setup2() != SUCCESS)
        {
                goto undo_setup2:
        }

          return SUCCESS;

undo_setup2:
        cleanup2();
undo_setup1:
        cleanup1();
        return FAILED;
}

This allows you to free and unregister things in the correct order without making failure steps with a lot duplicated calls that amounts to the same thing anyway. So it is very useful for handling error conditions where you need to free allocations that have happened up to a point, unmap some IO, etc.

Re:First Tutorial I've seen with Goto... (3, Informative)

frank_adrian314159 (469671) | about 4 months ago | (#47103651)

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:

if (!a) {
    if (!b) {
        if (!c) {
...

} } }

This code might be more simply understood as:

if (a) goto done;
if (b) goto done;
if (c) goto done;
...
done:
...

Re:First Tutorial I've seen with Goto... (1)

musicmaker (30469) | about 4 months ago | (#47105573)

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. (1)

Medievalist (16032) | about 4 months ago | (#47108563)

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.

Re:First Tutorial I've seen with Goto... (1)

tkotz (3646593) | about 4 months ago | (#47113571)

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:

if (a) { // Done - or log error A
}
else if (b) { // Done - or log error B
}
else if (c) { // Done - or log error C
}
else
{ ...
}

or it could be written more succinctly as:

if( !( a || b || c) ) { ...
}

Re:First Tutorial I've seen with Goto... (2)

shoor (33382) | about 4 months ago | (#47103871)

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.

Re:First Tutorial I've seen with Goto... (1)

c (8461) | about 4 months ago | (#47104193)

Any wise old vets want to chime in about when to use "goto" and when not to?

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.

Re:First Tutorial I've seen with Goto... (0)

Anonymous Coward | about 4 months ago | (#47104581)

What PP said: if that illustration of the use of "goto" isn't exception handling in a sheep's clothing, I don't know what is.

Writing modules near impossible (3, Interesting)

Eravnrekaree (467752) | about 4 months ago | (#47103379)

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 ... (1)

JackCorbae (693005) | about 4 months ago | (#47104249)

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"! :)

Re:Writing modules near impossible (0)

Anonymous Coward | about 4 months ago | (#47104269)

Sounds like there needs to be an apprenticeship system. Get eager, smart younguns to work side-by-side (virtually) with experienced devs and generate documentation. The kernel gets that code documented and the younguns get deep experience with the internals, plus really juicy resume' bait. That's pretty standard practice in other professions, or used to anyway.

Re:Writing modules near impossible (1)

Darinbob (1142669) | about 4 months ago | (#47104403)

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?

Re:Writing modules near impossible (0)

Anonymous Coward | about 4 months ago | (#47104409)

Most of the kernel interfaces that are used by driver writers are very well documented. There are large comments above important structures and functions, as well as a Documentation folder that describes large subsystem. Furthermore, there are numerous books that describe the kernel architecture from different perspectives - just pick the author you think best writes to your learning style.

The poorly-documented parts tend not to be in the core architecture, but in the fringes. The driver for that network card from 1990? The one that the kernel dev had to write by reverse engineering the hardware because the device wasn't documented? Those instances have poorer documentation (if any), and yet the source code reveals more information than if we had nothing. But if you have a new device for which you wish to write a Linux driver, the interfaces you need are all well-documented, and easier to use than the interfaces in other kernels such as Windows or FreeBSD (I know because I have programmed in all of them).

Re:Writing modules near impossible (-1)

Anonymous Coward | about 4 months ago | (#47105227)

I think you're missing the point. Since there's no documentation, it can be changed on a whim. Forgive me for being blunt, but Linux kernel devs mostly behave like little children: they hoard their toy and don't share and then complain when no commercial company wants to use it. They also would rather rant, rave and cuss instead of doing the mature thing and work things out for the betterment of the kernel. Documentation is rather hard work with little or no glory associated with it and most children want to be recognized.

It's just the way it is and will likely remain so. I use linux, but I will never depend on linux because it's really not well designed nor documented and to depend on it for commercial projectus is, well, a crapshoot at best.

Re:Writing modules near impossible (0)

Anonymous Coward | about 4 months ago | (#47124931)

I'd bet a large amount of us would disagree.
As a rule of thumb, good code is self-documenting and bad code needs comments.
Code in kernels (most of them) is usually of high quality, so it often points to a lack of understanding on the part of the reader.

In my day... (1)

dfn5 (524972) | about 4 months ago | (#47103495)

... any competent Unix admin could write a device driver. Now a days they barely know the grep.

Re:In my day... (0)

Anonymous Coward | about 4 months ago | (#47104903)

Riiiiight..

VERY OLD ARTICLE (0)

Anonymous Coward | about 4 months ago | (#47103653)

This is a repeat article that was on slashwhore about 6-8 years ago. Nothing new with this crap.

Thanks for the bug. (0)

Anonymous Coward | about 4 months ago | (#47103717)

You're fired!

"Daunting" (2)

Tyler Durden (136036) | about 4 months ago | (#47103761)

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:"Daunting" (0)

Anonymous Coward | about 4 months ago | (#47104081)

Learn Rust or Visual Basic.net for thee kernel safety...

Re:"Daunting" (1)

jythie (914043) | about 4 months ago | (#47104273)

There was never such a time. Slashdot has always had a pretty good variety of tech people, so for some it would be daunting, some it would not, depending on how close it was to their own domain knowledge.

Re:"Daunting" (1)

Tyler Durden (136036) | about 4 months ago | (#47104339)

Well then I guess I'll just have to take your word for it Mister 914043. ;)

Re:"Daunting" (1)

Ummon (15714) | about 4 months ago | (#47104419)

Take mine too.

Re:"Daunting" (0)

hax4bux (209237) | about 4 months ago | (#47104527)

And mine. There never was a world of "with many eyeballs, all bugs are shallow"

Re:"Daunting" (0)

musicmaker (30469) | about 4 months ago | (#47105583)

OpenSSL much?

Re:"Daunting" (1)

retchdog (1319261) | about 4 months ago | (#47108541)

and my axe!

Re:"Daunting" (1)

KingOfBLASH (620432) | about 4 months ago | (#47105147)

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:"Daunting" (1)

Buzer (809214) | about 4 months ago | (#47105549)

Many more of us have overloaded some operators and learned some other elements of the language.

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:"Daunting" (1)

KingOfBLASH (620432) | about 4 months ago | (#47105633)

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:"Daunting" (0)

Anonymous Coward | about 4 months ago | (#47105947)

woooosh ?

The parent meant that there is no overload of operator in C, so there is a very low likelihood that you ever "... overloaded a few operators," as you put it. That is a C++ feature. And don't get (Lin)us started on using C++ in the kernel.

Re:"Daunting" (1)

KingOfBLASH (620432) | about 4 months ago | (#47106563)

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:"Daunting" (0)

Anonymous Coward | about 4 months ago | (#47106865)

I think the point is that, strictly speaking, you can't overload functions in C. You can in C++ but C++ isn't C :).

Re:"Daunting" (2)

jones_supa (887896) | about 4 months ago | (#47106255)

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 reporting.

I got to the part about udev and closed the window (0)

Gothmolly (148874) | about 4 months ago | (#47104179)

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:I got to the part about udev and closed the win (1)

Anonymous Coward | about 4 months ago | (#47105217)

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 (4, Insightful)

Anonymous Coward | about 4 months ago | (#47104289)

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!

And "Hello, World" means you can write C! (0)

Anonymous Coward | about 4 months ago | (#47104723)

I think not

device driver (2)

riffraff (894) | about 4 months ago | (#47107419)

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).

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>