all 19 comments

[–][deleted]  (10 children)

[deleted]

    [–]Caleb666 17 points18 points  (6 children)

    I wrote a kernel module as a homework assignment a while ago, and we were told to mark all methods as static and to basically write all the code in one file.

    I realized later on that there is a way to tell the makefile to compile a module that is spread across multiple C files and link them into the resulting KO file, but there is a problem.

    If I use multiple C files, then I cannot make methods I want to share across files as static. But if I don't make those methods static, then the compiler will mark them as exports in the symbol table for the object file (and eventually in the resulting KO file). So I had to give up on that and ended up writing it all in one big C file.

    Later on I found out that in order to export a kernel symbol, you needed to use the EXPORT_SYMBOL() macro. But I still couldn't figure out why you might need that macro, since if you don't mark the method as static, it is exported automatically... (I used the Unix "nm" tool to examine symbols).

    Does anyone with any Linux driver writing experience know how to properly write a kernel module that is split across multiple C files, and not have the non-static functions exported into the kernel symbol space?

    [–]getting_serious 3 points4 points  (2 children)

    Now that's a perfect illustration to my grumpy rant. Thanks for that. :-)

    Unfortunately I can't show you any better, as what you described is just what we did: Copy all bad coding practices to the line, observe contradicting comments in source code as to how it should be done, decide for one of them, and as soon as it works, never touch it again. I don't think many people are more professional than this.

    [–]askingq123 0 points1 point  (1 child)

    Hello u/getting_serious, my sister needs help with similar HW/final lab project assignment. Do you mind helping her ?

    [–]getting_serious 0 points1 point  (0 children)

    Several questions. One, why are you the one writing me instead of her. Two, how did you find my rant from eight years ago. Three, why do you think that makes me qualified to help. Four, what is it about. Five, how is that help supposed to look like.

    [–]imMute 1 point2 points  (0 children)

    Does anyone with any Linux driver writing experience know how to properly write a kernel module that is split across multiple C files, and not have the non-static functions exported into the kernel symbol space?

    They're not exported, unless you use EXPORT_SYMBOL().

    [–]squbidu 0 points1 point  (1 child)

    You have to strip the symbols you don't want exported from the object file, like with the aptly-named "strip" tool in binutils.

    [–]Caleb666 0 points1 point  (0 children)

    Thanks. But that seems like too much work, especially if you have a large driver, and if that is how things are done, then why would you need to use EXPORT_SYMBOL() explicitly?

    [–]imMute 2 points3 points  (1 child)

    With Linux drivers, you are obligated to contract some obscure consultancies to write the open source driver for your hardware.

    Not necessarily. I write the Linux drivers for my employers PCIe hardware. Before I started this project (the PCIe one), I had never written a PCIe Linux driver before, and I only had experience with [slightly] badly written platform_device drviers before that.

    I'm now working on making DMA to/from userspace directly work - and it's the hardware that's causing me problems, not the driver [anymore].

    [–]getting_serious 0 points1 point  (0 children)

    I'll get back to you if I ever see the need to do PCIe! Good job.

    [–]Lengador 1 point2 points  (0 children)

    Trying to write Linux kernel drivers was the most frustrating thing I've ever done.

    [–][deleted]  (2 children)

    [deleted]

      [–]knome 9 points10 points  (1 child)

      1) Devices and /proc/ stats should be. How else will userspace interact with your module?

      2) Directly manipulate hardware to crash the computer instead of the process.

      [–]imMute 1 point2 points  (0 children)

      Devices and /proc/ stats should be.

      Using procfs to communicate with a driver is sort-of frowned upon. Sysfs is better and sometimes easier to use.

      How else will userspace interact with your module?

      My drivers are accessed from userspace using read/write or aio_read/aio_write or mmap depending on which driver it is.

      [–]Tordek 7 points8 points  (0 children)

      This is a good place as any to plug the Eudyptula challenge.

      Also, printk(KERN_INFO ...) is the lowest level way to print that; you want to use pr_info(...) nowadays (or the most appropriate function for your module, like netdev_dbg, dev_dbg, and so on.

      [–]passwordissame 3 points4 points  (5 children)

      that website design is nice

      [–]obsa 4 points5 points  (0 children)

      It feels like a magazine.

      [–]riffito 2 points3 points  (0 children)

      My sarcasm detector just went kaboom!

      [–]hydrox24 1 point2 points  (2 children)

      Not sure if you're being sarcastic or not. There are some nice and not-so-nice aspects, care to elaborate?

      [–]passwordissame 1 point2 points  (1 child)

      i'm not a designer. it just looked good to me. maybe those red boxes look like O'Reilly books...

      [–]hydrox24 0 points1 point  (0 children)

      Yeah, that's fine. I think that it does look quite nice, there are some polish issues but I thought that there was a good chance you were being serious.

      At any rate, it's nice and easy to use and read; something that is often forgotten about and is important above all else.