Everything Penguin

Focusing on Linux-based Operating Systems
htDig Search:

Operating Systems
  • /pub/OS/Linux

  • Storage
  • File Systems
  • HPC
  • /pub/Storage

  • Networking
  • /pub/Networking

  • Network Services
  • /pub/NetworkServices

  • Security
  • /pub/Security
  • Keytool/OpenSSL

  • Clustering
  • HA
  • DRM

  • Development
  • Design
  • C/C++
  • Java
  • Perl
  • Python
  • Shell
  • Web / J2EE

  • Not Linux ?
  • BSD
  • HP-UX
  • Mac
  • Solaris
  • VM
  • Windows
  • /pub/OS

  • Other
  • /pub
  • /pub/3rdParty
  •  Parent Directory

    Linux Kernel Hacking
    Brett Lee
    ==============================
    
    
    This is an area of interest, but *not* my area of expertise.  Caveat emptor!
    
    
    
    Topics:
    -----------
    1. Functions of the Linux Kernel
    2. The base Kernel
    3. Kernel Modules
    4. Building a Custom Kernel (easiest way to hack the kernel)
    5. Patching a Kernel (another easy way to hack the kernel)
    6. Writing a Kernel Module (another way to hack the kernel)
    7. Writing Kernel Code (really hacking the kernel)
    8. Misc
    
    
    
    
    
    1. Functions of the Kernel
    ---------------------------------------
    
    The kernel is the kindergarden teacher.  While all the other kids (processes)
    are running around oblivious (or not) to the rules and making all kinds of
    demands and requests, the kindergarden teacher ensures that everyone plays
    fairly (or gets a time out) and does things for them (like getting the blue
    paint fron the top shelf) that you don't want kids doing themselves.
    
    In short, processes can't be trusted to know the rules or play nice, so the
    kernel enforces the rules, ensures that the processes share the resources,
    and (in most cases) handles access to the hardware (blue paint).
    
    To keep with our analogy, kindergarden teachers (and Linux kernels) must be
    prepared to handle different tasks, and some tasks will be done by some 
    teachers and never done by others (earthquake drills in CA vs. snow storm
    preparedness in NY).  The kernel uses modules to support these types of
    tasks, thus the same "base" kernel could be used in LA and NY, but different
    modules would be used.  When a kernel module is loaded, it is running as
    the kernel.
    
    
    
    
    2. Looking into a Kernel
    ---------------------------------------
    
    What's in a compiled kernel:
    
      * Stuff to make it boot and load properly.
      * Routines to initialize itself and allow other processes to run.
      * System calls API
      * Routines to run when it doesn't know what to do (e.g. panic(), oops())
      * Debugging info, symbol tables, etc. (ok, maybe not all "in" the kernel).
    
    
    Where is the kernel:
    
      * In the /boot/ directory, probably in a file called bzImage.
    
    
    What happened to vmlinuz?  Or for that matter, vmlinux?  What's this bzImage?
    
      * vmlinux was the default compilied kernel.  but it was statically linked
      * and
          got too big long ago.
      * vmlinuz was next (AFAIK) default compilied kernel.  it also got too big.
      * bzImage (zImage) was the next default compiled image.
        - it is a Big zImage (not bzip2)
        - although compressed, this image is unique as it is spread across the
          different memory regions
    
    
    What tools can be used to look at the compiled kernel image:
    
      * to manually unzip the bzimage, you will first need remove the header:
        - everything up to (but not including): (0x) 1F 8B 08 00
    
      * the trusty 'file' command shows basic info:
        ~> file vmlinuz-2.6.18-8.el5
        /boot/vmlinuz-2.6.18-8.el5: ELF 64-bit LSB shared object, AMD x86-64, version 1, stripped
    
      * the kernel is an elf binary, so 'readelf' can be used:
        ~> readelf -a vmlinuz-2.6.18-8.el5
        typical kernels return the ELF header, but not much more
    
      * objdump can be used to read a bit more:
        ~> objdump -x vmlinuz-2.6.18-8.el5
        ... <cut> ...
        no symbols
    
      * symbols can typically be read from and ELF using 'nm'
        ~> nm vmlinuz-2.6.18-8.el5
        nm: vmlinuz-2.6.18-8.el5: no symbols
    
    
      But as shown above, there are no symbols in the kernel.
      Should I care.  WTF are symbols.
    
        * Symbols are names of routines, structures, variables, lists, and more.
        * In short, symbols are the "objects" that are exposed outside of the
        * kernel.
        * So the actual symbols are in the kernel, somewhere.
        * When source files are compiled to an object files, each object file
        * contains
            a newly created symbol table.
          - Symbols are not yet mapped to memory locations.
          - Memory location for most symbols will be location "00000...".
        * When the object files are linked, the linker combines each objects 
           symbol tables to assign memory locations to all the objects, and the
           links calls to the objects to those locations in memory.  Maybe.  Like
           I said at the top, this is not my area.  See the ELF Format docs. :)
           - Result is a fully mapped symbol table in the binary
             - that is often stripped! :)
    
    
      Ok, but where are the symbols in the Linux kernel:
    
        * The symbol table is not in the binary but instead in the file
        * /boot/System.map. 
        * To look at the symbol table:
            ~>grep " kmem_cache_alloc"  /boot/System.map-2.6.18-8.el5
            ffffffff8000a7ea T kmem_cache_alloc
            ffffffff800cc4bb T kmem_cache_alloc_node
        * Compare with the running kernel:
            ~>grep -i kmem_cache_alloc /proc/kallsyms 2>/dev/null | head
            ffffffff8000a7ea T kmem_cache_alloc
            ffffffff800cc4bb T kmem_cache_alloc_node
    
    
      How many symbols could there be:
        ~> wc -l /proc/kallsyms
           25171
    
    
      And what is the /boot/symvers-2.6.18-8.el5.gz? (Redhat & friends)
    
       * If you have one, it is a zip of the Module.symvers (module symbols map).
       * To view it, copy it to a scratch dir, unzip it and:
          ~>grep kmem_cache_alloc symvers-2.6.18-8.el5
          0x4c503ced      kmem_cache_alloc        vmlinux EXPORT_SYMBOL
          0x2a04cc33      kmem_cache_alloc_node   vmlinux EXPORT_SYMBOL
    
    
    
    Other ways to look at the kernel - virtual filesystems.
    
      What is the /proc directory for:  Processes and hardware
    
        Could write several volumes here and not say enough.
    
    
      What is the /sys directory:  Block devices.
    
        Ref:  http://www.win.tue.nl/~aeb/linux/lk/lk.html
        Sysfs is a virtual filesystem that describes the devices known to
          the system from various viewpoints.
        By default it is mounted on /sys.
        The basic building blocks of the hierarchy are kobjects.
        A struct kobject represents a kernel object, maybe a device or so,
         such as the things that show up as directory in the sysfs filesystem.
    
    
    
    
    
    
    Looking at the Kernel Modules
    ==============================
    
    Looking at the modules directory, we see:
    
      ~> pwd
      /lib/modules/2.6.18-8.el5
      ~> ll
      total 1052
      lrwxrwxrwx 1 root root     44 Nov  1  2007 build -> ../../../usr/src/kernels/2.6.18-8.el5-x86_64
      drwxr-xr-x 2 root root   4096 Aug 19  2009 extra
      drwxr-xr-x 9 root root   4096 Nov  1  2007 kernel
      drwxr-xr-x 2 root root   4096 Nov  1  2007 misc
      -rw-r--r-- 1 root root 232666 Aug 19  2009 modules.alias
      -rw-r--r-- 1 root root     69 Aug 19  2009 modules.ccwmap
      -rw-r--r-- 1 root root 175701 Aug 19  2009 modules.dep
      -rw-r--r-- 1 root root     73 Aug 19  2009 modules.ieee1394map
      -rw-r--r-- 1 root root    375 Aug 19  2009 modules.inputmap
      -rw-r--r-- 1 root root   2160 Aug 19  2009 modules.isapnpmap
      -rw-r--r-- 1 root root     74 Aug 19  2009 modules.ofmap
      -rw-r--r-- 1 root root 160532 Aug 19  2009 modules.pcimap
      -rw-r--r-- 1 root root   4033 Aug 19  2009 modules.seriomap
      -rw-r--r-- 1 root root  92119 Aug 19  2009 modules.symbols
      -rw-r--r-- 1 root root 319111 Aug 19  2009 modules.usbmap
      lrwxrwxrwx 1 root root      5 Nov  1  2007 source -> build
      drwxr-xr-x 2 root root   4096 Mar 15  2007 updates
      drwxr-xr-x 2 root root   4096 Mar 15  2007 weak-updates
      ~>
    
    
      Those are the modules built for the 2.6.18-8.el5 kernel.  The are loaded
      automagically at boot time, or are loaded manually via the 'modprobe' command.
    
      For example:
      ~> cat /etc/modprobe.conf
      alias eth0 tg3
      alias eth1 tg3
      alias scsi_hostadapter aic7xxx
      alias scsi_hostadapter1 3w-9xxx
      ~> /sbin/lsmod | grep -E 'aic7xxx|3w-9xxx'
      aic7xxx               162553  0
      scsi_transport_spi     59713  1 aic7xxx
      scsi_mod              184057  7
      sr_mod,usb_storage,sg,aic7xxx,scsi_transport_spi,3w_9xxx,sd_mod
      ~> 
    
      At boot time:
    
        The file /etc/modprobe.conf is read and those modules are loaded.
          Note that modprobe.conf replaces /etc/modules.conf.
        If modprobe.conf is not found, modprobe looks for modules in /etc/modprobe.d/.
    
    
      The modprobe command (from the man page):
    
        modprobe intelligently adds or removes a module from the Linux kernel.
          by intelligently, it means that modprobe is aware of the dependencies
          that a module may have, and it will load all the dependencies prior
          to loadiong the module.
        modprobe looks for modules in the directory /lib/modules/`uname -r`/.
    
      The dependencies are listed in the file /lib/modules/`uname -r`/modules.dep.
        It is a colon delimited list of "module name : module_dep module_dep ..."
        Where do the dependencies come from:  symbols, of course. :)
        Every module has (provides) some symbols and requires other symbols.
        If the required symbols are in another module, that module is added
          as a dependency in modules.dep.
    
        modules.dep is created and recreated by depmod.
        A couple handy depmod commands are:
    
          ~> depmod -A         // check to see if there are updates before
                               // doing the whole tree
          ~> depmod -n         // do a dry run of the whole module tree
    
          ** Note: the "tree" is determined by depmod.conf (see below).
    
        For example:
    
          ~> /sbin/depmod -n > out
          ~> wc -l out
          11392 out
          ~> grep ^# out
    
    
      The /lib/modules/`uname -r`/ directory has lots of directories for
        modules in there:
      
        kernel/
        misc/
        extra/
        updates/
        weak-updates/
    
        The order which these directories is searched (or not) is governed by
          the depmod.conf file.  Below is the dist example:
          ~> cat /etc/depmod.d/depmod.conf.dist
          #
          # depmod.conf
          #
          # override default search ordering for kmod packaging
          search updates extra built-in weak-updates
          ~>
    
        Regarding weak-updates, if you like binaries without man pages or any
          documentation (except for the usage() output), you will love:
          /sbin/weak-modules (part of the module-init-tools package)
          For a discussion, see:
          http://www.centos.org/modules/newbb/print.php?form=1&topic_id=13981&forum=37&order=ASC&start=0
    
        Not enough places for modules, then check out DKMS:
          http://www.linuxjournal.com/article/6896
    
    
    
    
    
    4. Building a Custom Kernel (easiest way to hack the kernel)
    ----------------------------------------------------------------
    
    Build the kernel, your way:
    
        Download kernel source to from:  http://www.kernel.org/
        make menuconfig and look for slub (I think as of 2.6.26)
          - yep, it's there.  not the default.
        also look for different scheduler besides CFS
          nope
          http://kerneltrap.org/node/8059
          consider patching it with BFS
        ok, so going with w/ CFS.  No disrespect to Ingo, but this build is not
    for a workstation
        So wtf does a tickless kernel mean in practice?
          it shuts down the CPU for 1.5 seconds, if ...
          arrgh! see: http://kerneltrap.org/node/6750
        Real Time kernel at:
          https://rt.wiki.kernel.org/index.php/Main_Page
        RT + HPC:
          http://events.linuxfoundation.org/slides/lfcs2010_singhvi.pdf
        Howto at:
          http://www.tuxradar.com/content/how-compile-linux-kernel
    
        Anyway, you can sure do a lot of kernel "hacking" with other people's code
    
    
    
    
    ** When you are building your kernel, you can also build docs.
    
    kernel-x.x.x ~> make help
    Cleaning targets:
      clean           - Remove most generated files but keep the config and
                        enough build support to build external modules
      mrproper        - Remove all generated files + config + various backup files
      distclean       - mrproper + remove editor backup and patch files
    
    Configuration targets:
      config          - Update current config utilising a line-oriented program
      nconfig         - Update current config utilising a ncurses menu based
    program
      menuconfig      - Update current config utilising a menu based program
      xconfig         - Update current config utilising a QT based front-end
      gconfig         - Update current config utilising a GTK based front-end
      oldconfig       - Update current config utilising a provided .config as base
      localmodconfig  - Update current config disabling modules not loaded
      localyesconfig  - Update current config converting local mods to core
      silentoldconfig - Same as oldconfig, but quietly, additionally update deps
      defconfig       - New config with default from ARCH supplied defconfig
      savedefconfig   - Save current config as ./defconfig (minimal config)
      allnoconfig     - New config where all options are answered with no
      allyesconfig    - New config where all options are accepted with yes
      allmodconfig    - New config selecting modules when possible
      alldefconfig    - New config with all symbols set to default
      randconfig      - New config with random answer to all options
      listnewconfig   - List new options
      oldnoconfig     - Same as silentoldconfig but set new symbols to n (unset)
    
    Other generic targets:
      all             - Build all targets marked with [*]
    * vmlinux         - Build the bare kernel
    * modules         - Build all modules
      modules_install - Install all modules to INSTALL_MOD_PATH (default: /)
      firmware_install- Install all firmware to INSTALL_FW_PATH
                        (default: $(INSTALL_MOD_PATH)/lib/firmware)
      dir/            - Build all files in dir and below
      dir/file.[oisS] - Build specified target only
      dir/file.lst    - Build specified mixed source/assembly target only
                        (requires a recent binutils and recent build (System.map))
      dir/file.ko     - Build module including final link
      modules_prepare - Set up for building external modules
      tags/TAGS       - Generate tags file for editors
      cscope          - Generate cscope index
      kernelrelease   - Output the release version string
      kernelversion   - Output the version stored in Makefile
      headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH
                        (default: /tmp/linux-2.6.37/usr)
    
    Static analysers
      checkstack      - Generate a list of stack hogs
      namespacecheck  - Name space analysis on compiled kernel
      versioncheck    - Sanity check on version.h usage
      includecheck    - Check for duplicate included header files
      export_report   - List the usages of all exported symbols
      headers_check   - Sanity check on exported headers
      headerdep       - Detect inclusion cycles in headers
      coccicheck      - Check with Coccinelle.
    
    Kernel packaging:
      rpm-pkg             - Build both source and binary RPM kernel packages
      binrpm-pkg          - Build only the binary kernel package
      deb-pkg             - Build the kernel as an deb package
      tar-pkg             - Build the kernel as an uncompressed tarball
      targz-pkg           - Build the kernel as a gzip compressed tarball
      tarbz2-pkg          - Build the kernel as a bzip2 compressed tarball
      perf-tar-src-pkg    - Build perf-2.6.37.tar source tarball
      perf-targz-src-pkg  - Build perf-2.6.37.tar.gz source tarball
      perf-tarbz2-src-pkg - Build perf-2.6.37.tar.bz2 source tarball
    
    Documentation targets:
     Linux kernel internal documentation in different formats:
      htmldocs        - HTML
      pdfdocs         - PDF
      psdocs          - Postscript
      xmldocs         - XML DocBook
      mandocs         - man pages
      installmandocs  - install man pages generated by mandocs
      cleandocs       - clean all generated DocBook files
    
    Architecture specific targets (x86):
    * bzImage      - Compressed kernel image (arch/x86/boot/bzImage)
      install      - Install kernel using
                      (your) ~/bin/installkernel or
                      (distribution) /sbin/installkernel or
                      install to $(INSTALL_PATH) and run lilo
      fdimage      - Create 1.4MB boot floppy image (arch/x86/boot/fdimage)
      fdimage144   - Create 1.4MB boot floppy image (arch/x86/boot/fdimage)
      fdimage288   - Create 2.8MB boot floppy image (arch/x86/boot/fdimage)
      isoimage     - Create a boot CD-ROM image (arch/x86/boot/image.iso)
                      bzdisk/fdimage*/isoimage also accept:
                      FDARGS="..."  arguments for the booted kernel
                      FDINITRD=file initrd for the booted kernel
    
      i386_defconfig           - Build for i386
      x86_64_defconfig         - Build for x86_64
    
      make V=0|1 [targets] 0 => quiet build (default), 1 => verbose build
      make V=2   [targets] 2 => give reason for rebuild of target
      make O=dir [targets] Locate all output files in "dir", including .config
      make C=1   [targets] Check all c source with $CHECK (sparse by default)
      make C=2   [targets] Force check of all c source with $CHECK
    
    Execute "make" or "make all" to build all targets marked with [*]
    For further info see the ./README file
    
    kernel-x.x.x ~> 
    
    
    
    
    
    
    
    5. Patching a Kernel (another way to hack the kernel)
    ------------------------------------------------------------
    
    Patch and build.  What could be easier? :)
    
    
    
    Here's the patch part:
    -------------------------
    
    
    ~> cd linux-2.6.34.7
    ~> ls
    arch     crypto         fs       Kbuild       Makefile  REPORTING-BUGS  sound
    block    Documentation  include  kernel       mm        samples         tools
    COPYING  drivers        init     lib          net       scripts         usr
    CREDITS  firmware       ipc      MAINTAINERS  README    security        virt
    
    ~> wget http://ck.kolivas.org/patches/bfs/2.6.34/2.6.34.7-sched-bfs-350.patch
    ~> wget http://ck.kolivas.org/patches/bfs/2.6.34/2.6.34.7-sched-bfs-357-360.patch
    
    ~> patch -p1 < 2.6.34.7-sched-bfs-350.patch
    patching file Documentation/sysctl/kernel.txt
    patching file include/linux/init_task.h
    patching file include/linux/sched.h
    patching file kernel/sysctl.c
    patching file kernel/sched_bfs.c
    patching file kernel/posix-cpu-timers.c
    patching file kernel/exit.c
    patching file mm/oom_kill.c
    patching file init/Kconfig
    patching file kernel/delayacct.c
    patching file fs/proc/base.c
    patching file init/main.c
    patching file Documentation/scheduler/sched-BFS.txt
    patching file lib/Kconfig.debug
    patching file arch/powerpc/platforms/cell/spufs/sched.c
    patching file kernel/sched.c
    Hunk #2 succeeded at 9212 (offset 3 lines).
    patching file include/linux/ioprio.h
    patching file kernel/kthread.c
    patching file kernel/slow-work.c
    
    
    ~> patch -p1 < 2.6.34.7-sched-bfs-357-360.patch
    patching file include/linux/jiffies.h
    patching file include/linux/sched.h
    Hunk #1 FAILED at 1548.
    1 out of 1 hunk FAILED -- saving rejects to file include/linux/sched.h.rej
    patching file kernel/sched_bfs.c
    Hunk #1 succeeded at 186 (offset -2 lines).
    Hunk #2 succeeded at 716 (offset -17 lines).
    Hunk #3 succeeded at 789 (offset -2 lines).
    Hunk #4 succeeded at 812 (offset -17 lines).
    Hunk #5 succeeded at 840 (offset -2 lines).
    Hunk #6 succeeded at 867 (offset -17 lines).
    Hunk #7 succeeded at 1318 (offset -3 lines).
    Hunk #8 succeeded at 2709 (offset -4 lines).
    Hunk #9 succeeded at 2753 (offset -3 lines).
    Hunk #10 succeeded at 6607 (offset -4 lines).
    Hunk #11 succeeded at 6718 (offset -4 lines).
    ~>
    
    
    Hunk #1 FAILED !  How much is a hunk.  Better look at the rejects file..
    
      ~> cat include/linux/sched.h.rej
      ***************
      *** 1548,1554 ****
    
        static inline void print_scheduler_version(void)
        {
      -       printk(KERN_INFO"BFS CPU scheduler v0.357 by Con Kolivas.\n");
        }
    
        static inline int iso_task(struct task_struct *p)
      --- 1548,1554 ----
    
        static inline void print_scheduler_version(void)
        {
      +       printk(KERN_INFO"BFS CPU scheduler v0.360 by Con Kolivas.\n");
        }
    
        static inline int iso_task(struct task_struct *p)
      ~>
    
    Aha, the last patch expected to find a line w/357 in it.  Above the 350 patch
    was applied, not the 357 patch!  Starting again and using the correct patch
    sequence should solve the issue:
    
    
      ~> wget http://ck.kolivas.org/patches/bfs/2.6.34/2.6.34.7-sched-bfs-357.patch
      ~> wget http://ck.kolivas.org/patches/bfs/2.6.34/2.6.34.7-sched-bfs-357-360.patch
    
      ~> patch -p1 < 2.6.34.7-sched-bfs-357.patch
      patching file Documentation/sysctl/kernel.txt
      patching file include/linux/init_task.h
      patching file include/linux/sched.h
      patching file kernel/sysctl.c
      patching file kernel/sched_bfs.c
      patching file kernel/posix-cpu-timers.c
      patching file kernel/exit.c
      patching file mm/oom_kill.c
      patching file init/Kconfig
      patching file kernel/delayacct.c
      patching file fs/proc/base.c
      patching file init/main.c
      patching file Documentation/scheduler/sched-BFS.txt
      patching file lib/Kconfig.debug
      patching file arch/powerpc/platforms/cell/spufs/sched.c
      patching file kernel/sched.c
      Hunk #2 succeeded at 9212 (offset 3 lines).
      patching file include/linux/ioprio.h
      patching file kernel/kthread.c
      patching file kernel/slow-work.c
    
      ~> patch -p1 < 2.6.34.7-sched-bfs-357-360.patch
      patching file include/linux/jiffies.h
      patching file include/linux/sched.h
      patching file kernel/sched_bfs.c
      ~>
    
      That's what I'm talkin about!  Problems can be solved!
      Running make <whatever>config, we see:
    
        CONFIG_SCHED_BFS:
        The Brain Fuck CPU Scheduler for excellent interactivity and
        responsiveness on the desktop and solid scalability on normal
        hardware. Not recommended for 4096 CPUs.
    
        Currently incompatible with the Group CPU scheduler, and RCU TORTURE
        TEST so these options are disabled.
    
        Say Y here.
     
        Symbol: SCHED_BFS [=y]
     
        Prompt: BFS cpu scheduler
          Defined at init/Kconfig:26
          Location:
            -> General setup        
    
    
      Next time, here are a couple more options:
        cat 2.6.34.7-sched-bfs-357-360.patch | patch -p1 --dry-run
        or for bzip'd files:
        bzip2 -dc /location/to/patch.bz2 | patch -p1 --dry-run
    
    
      Here's the build part:
      --------------------------
    
      The build process was discussed above, but with the happy path.
      With the kernel patched, all bets are off.
    
      What kind of problems might arise:
    
        Undefined functions:
    
          C compilers these days require that functions are declared.
          The declaration is a prototype that helps the compiler check
          for errors when the function is called.
          The solution is to declare the function before its first use.
    
        Symbol collisions:
    
          Most likely the same name is used in two different global contexts.
          The solution is to change their scope so that the correct binding occurs.
          Options include:
            STB_LOCAL 0
            STB_GLOBAL 1
            STB_WEAK 2
            STB_LOPROC 13
            STB_HIPROC 15
    
        Terms, as well as pro's and con's of each type of binding, to ponder:
    
          local symbols (typically those declared static.  inline also?)
          global symbols (also known as external or exported symbols)
          weak symbols 
          static binding (in general, this is binding before run-time that remains
                          bound during execution.  in practice, this is link-time
                          binding with a static library)
          dynamic binding (in general, this is the appearance of binding before
                           run-time, with the actual binding occuring at run-time.
                           in practice, this is binding with a dynamic library)
          lazy binding (typically the default for dynamic libraries, in that they
                        do not bind all symbols, but instead bind them as needed)
          late binding (dynamic binding, run-time binding; applies to virtual
                        functions and symbol preemption)
          symbol preemption (overriding global symbols defined elsewhere.
                             typically this would be in a shared library.)
    
    
      References:
    
      http://software.intel.com/en-us/articles/software-convention-models-using-elf-visibility-attributes/
      http://www.developers.net/intelisnshowcase/view/472
      http://us.generation-nt.com/answer/elf-weak-symbols-lazy-dynamic-binding-help-182966311.html
      http://download.oracle.com/docs/cd/E19963-01/819-0690/chapter2-93321/index.html
      http://developers.sun.com/solaris/articles/linker_mapfiles.html
      http://www.iecc.com/linker/linker03.html
    
    
    
    
    
    
    6. Writing a Kernel Module (another way to hack the kernel)
    
      Modules (like code in the base kernel) can ONLY call kernel functions.
    
      Like the kernel, modules "are" written in C:
    
        OO developers, don't worry.  C is used to create Kernel Objects. :)
                                                              ^^^^^^^
        http://kerneltrap.org/node/2067
        http://www.linuxquestions.org/questions/programming-9/c-or-pure-c-for-linux-kernel-module-linux-device-driver-development-what-to-use-353924/
    
        Test:  See if a g++ compiled module is loadable.
        I tried for a bit, and gave up after finding the chain of highly
          customized Makefile(s) in the Linux source tree.
    
    
      The compiled module will be an ELF binary, so all the ELF stuff above applies.
    
      Writing a module and load it into the kernel - the first one is easy!
    
        http://www.tldp.org/LDP/lkmpg
    
      Here's a well written, interesting, but out-of-date HOWTO:
    
        http://tldp.org/HOWTO/Module-HOWTO/
    
    
    
    
    
    7. Writing Kernel Code (really hacking the kernel)
    ------------------------------------------------------------
    
    You can read the APIs here:
      http://www.kernel.org/doc/htmldocs/kernel-api/
    
    
    
    
    
    
    8. Misc
    ------------------------------------------------------------
    
      * kmalloc/vmalloc (k=contiguous, v=virtually contiguous) allocation
        - both in kernel space.
        - see:  http://kerneltrap.org/node/4020
    
      * kernels are loaded differently into memory
        - zImage is loaded into the first 640K
        - bzImage (Big zImage) is loaded into high memory ( > 1 M)
    
      * kernel booting - TMI
        - http://www.faqs.org/docs/kernel_2_4/lki-1.html
    
    
    
    
    For more, see:
    
        http://www.kernel.org/doc/htmldocs/kernel-api/
        http://ldn.linuxfoundation.org/article/kernel-symbols-whats-available-your-module-what-isnt
        or:  man 'nm|readelf|objdump'
        http://www.linuxjournal.com/article/1059
        http://www.skyfree.org/linux/references/ELF_Format.pdf
        http://www.airs.com/blog/archives/38
        http://tldp.org/HOWTO/Program-Library-HOWTO/
        http://developers.sun.com/solaris/articles/linker_mapfiles.html
        http://www.serc.iisc.ernet.in/ComputingFacilities/systems/Tesla_Doc/Intel_C%2B%2B_Compiler/main_cls/bldaps_cls/cppug_ccl/bldaps_sym_pre_cl.htm
    
    
        Symbol preemption
        Relocateable Object File
    

    Other Sites

    RFC's
  • FAQ's
  • IETF
  • RFC Sourcebook

  • Linux
  • Linux - Intro
  • Linux Kernel
  • Linux Kernel (LKML)
  • Bash - Intro
  • Bash - Advanced
  • Command Line
  • System Administration
  • Network Administration
  • Man Pages (& more)
  • More Guides
  • Red Hat Manuals
  • HOWTO's

  • Reference/Tutorials
  • C++ @ cppreference
  • C++ @ cplusplus
  • CSS @ echoecho
  • DNS @ Zytrax
  • HTML @ W3 Schools
  • Java @ Sun
  • LDAP @ Zytrax
  • Linux @ YoLinux
  • MySQL
  • NetFilter
  • Network Protocols
  • OpenLDAP
  • Quagga
  • Samba
  • Unix Programming



  • This site contains many of my notes from research into different aspects of the Linux kernel as well as some of the software provided by GNU and others. Thouugh these notes are not fully comprehensive or even completetly accurate, they are part of my on-going attempt to better understand this complex field. And, they are your to use.

    Should you wish to report any errors or suggestions, please let me know.

    Should you wish to make a donation for anything you may have learned here, please direct that donation to the ASPCA, with my sincere thanks.

    Brett Lee
    Everything Penguin

    The code for this site, which is just a few CGI scripts, may be found on GitHub (https://github.com/userbrett/cgindex).

    For both data encryption and password protection, try Personal Data Security (https://www.trustpds.com).


    "We left all that stuff out. If there's an error, we have this routine called 'panic', and when its called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"

        - Dennis Ritchie on Unix (vs Multics)


    Google
    [ Powered by Red Hat Linux ] [ Powered by Apache Server] [ Powered by MySQL ]

    [ Statistics by AWStats ]