suggestions for new kernel hacking-HOWTO

suggestions for new kernel hacking-HOWTO

[Andrew Ebling]

Hi all,

I am considering putting together a new, more in depth kernel hacking
HOWTO.  

The existing HOWTO (by Rusty), although an excellent source of technical
information does not contain much practical advice on how to get
started.

Therefore I would like to propose the following structure (for your
comments):

- Intro
        - Who is this document for etc.
        - Prerequisites

- Key Kernel Concepts
	(placing these in a good order is important)
        - virtual memory/memory management
        - virtual file system/IO management
        - process/scheduling
        - contexts/interrupts/exceptions
        - system calls/signals/IPC
        - boot sequence

- Kernel source tour
        What goes where in the source tree

- Tools
        - source code navigation (lxr, cscope, tags)
        - source code manipulation (vim, diff, patch, RCS/CVS)

- How do I... ?
        - Print messages to kernel logs
        - create a new module
        - Add a system call
        - write ioctls
        - Add a /proc entry
        - Write a driver for a new device
        - Add an option to the kernel configuation

- Kernel Debugging
        - A word on debugging
        - Different approaches
                - local running kernel
                - UML
        - two box debugging (I have already write a sort of mini HOWTO
on this, which can be found at
http://www.kernelhacking.org/docs/2boxdebugging.txt)
        	- Setting up
                	- hardware
                	- software
        	- Preparing the source
        	- Example debugging session
        	- Troublshooting

- Kernel Profiling
	How to find bottlenecks

- Hacking Tips
        - Avoiding deadlock
	<add to this list!>

- Books

- FAQ

- Links

- where to get help
        - mailing lists
        - irc

- references

I'm interested in hearing from seasoned kernel hackers (on what
should/shouldn't go in this HOWTO) and newbies (what is particularly
puzzling or not clear when setting out), hence the cross posting of this
message.

I do not have all the know how/experience required to write this
document single handed, so I am also looking for willing volunteers to
contribute their expertise/know how/tips and to proof read/make
suggestions as the document progresses.

My website (http://www.kernelhacking.org) will serve as a base for this
project.

best regards,

Andy

PS.  Please post general discussion back to the list(s) as appropriate
and post specific ideas/requests to my personal address only.  Thanks :)

Re: suggestions for new kernel hacking-HOWTO

[Arnaldo Carvalho de Melo]

Em Thu, Aug 23, 2001 at 10:29:27PM +0100, Andrew Ebling escreveu:
> Hi all,
> 
> I am considering putting together a new, more in depth kernel hacking
> HOWTO.  
> 
> The existing HOWTO (by Rusty), although an excellent source of technical
> information does not contain much practical advice on how to get
> started.
> 
> Therefore I would like to propose the following structure (for your
> comments):
> 
> - Intro
>         - Who is this document for etc.
>         - Prerequisites
> 
> - Key Kernel Concepts
> 	(placing these in a good order is important)
>         - virtual memory/memory management
>         - virtual file system/IO management
>         - process/scheduling
>         - contexts/interrupts/exceptions
>         - system calls/signals/IPC
>         - boot sequence
> 
> - Kernel source tour
>         What goes where in the source tree
> 
> - Tools
>         - source code navigation (lxr, cscope, tags)

sourcenav (http://sources.redhat.com/sourcenav)
cflow (+ graphviz)

>         - source code manipulation (vim, diff, patch, RCS/CVS)

interdiff

> 
> - How do I... ?
>         - Print messages to kernel logs
>         - create a new module
>         - Add a system call
>         - write ioctls
>         - Add a /proc entry
>         - Write a driver for a new device
>         - Add an option to the kernel configuation
> 
> - Kernel Debugging
>         - A word on debugging
>         - Different approaches
>                 - local running kernel
>                 - UML
>         - two box debugging (I have already write a sort of mini HOWTO
> on this, which can be found at
> http://www.kernelhacking.org/docs/2boxdebugging.txt)
>         	- Setting up
>                 	- hardware
>                 	- software
>         	- Preparing the source
>         	- Example debugging session
>         	- Troublshooting

kdb
ikd
linux trace toolkit

and here one could search all the DEBUG features already in the kernel
(WAITQÜEUE_DEBUG, SLAB poisoning, etc) and send a nice patch to Alan/Linus
so that it becomes configurable at make config/menuconfig/the others

> 
> - Kernel Profiling
> 	How to find bottlenecks

linux trace toolkit, docs by Andrew Morton on low latency, etc

> 
> - Hacking Tips
>         - Avoiding deadlock
> 	<add to this list!>
> 
> - Books

already in http://www.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html
and Documentation/kernel-docs.txt

> 
> - FAQ
> 
> - Links
> 
> - where to get help
>         - mailing lists
>         - irc
> 
> - references
> 
> I'm interested in hearing from seasoned kernel hackers (on what
> should/shouldn't go in this HOWTO) and newbies (what is particularly
> puzzling or not clear when setting out), hence the cross posting of this
> message.
> 
> I do not have all the know how/experience required to write this
> document single handed, so I am also looking for willing volunteers to
> contribute their expertise/know how/tips and to proof read/make
> suggestions as the document progresses.
> 
> My website (http://www.kernelhacking.org) will serve as a base for this
> project.
> 
> best regards,
> 
> Andy
> 
> PS.  Please post general discussion back to the list(s) as appropriate
> and post specific ideas/requests to my personal address only.  Thanks :)


                        - Arnaldo

Re: suggestions for new kernel hacking-HOWTO

[Pragnesh Sampat]

> - Key Kernel Concepts
> 	(placing these in a good order is important)
>         - virtual memory/memory management
>         - virtual file system/IO management
>         - process/scheduling
>         - contexts/interrupts/exceptions
>         - system calls/signals/IPC
>         - boot sequence

> - Kernel source tour
>         What goes where in the source tree
> 

I am not sure if these two sections are suitable in this howto.  It
seems pretty ambitious, since they can get very large and the
books/resources sections can take care of this.  The book "Linux
Device Drivers" by Rubini and Corbet has got a section on source tour.

> - How do I... ?
>         - Print messages to kernel logs
>         - create a new module
>         - Add a system call
>         - write ioctls
>         - Add a /proc entry
>         - Write a driver for a new device
>         - Add an option to the kernel configuation
> 
> - Kernel Debugging
>         - A word on debugging
>         - Different approaches
>                 - local running kernel
>                 - UML
>         - two box debugging (I have already write a sort of mini HOWTO
> on this, which can be found at
> http://www.kernelhacking.org/docs/2boxdebugging.txt)
>         	- Setting up
>                 	- hardware
>                 	- software
>         	- Preparing the source
>         	- Example debugging session
>         	- Troublshooting
> 

Kernel Debugging can probably go ahead of the "How do I...?" section,
since in practice you probably need some variant of the the setup you
have described before you start, unless you are just trying out a
trivial module.

In fact, if the concepts section is not there, the whole document
seems to have the structure of how to do something, with sub sections
of varying length (after all, it is hacking HOWTO).

-Pragnesh

Re: suggestions for new kernel hacking-HOWTO

[Rusty Russell]

In message <998602169.405.21.camel@elixr.jfreak> you write:
> Hi all,
> 
> I am considering putting together a new, more in depth kernel hacking
> HOWTO.  
> 
> The existing HOWTO (by Rusty), although an excellent source of technical
> information does not contain much practical advice on how to get
> started.

This sounds fantastic!  I'd always hoped that my document would be a
starting point for something more substantial, yet it never happened
8(

One word of warning: beware tying it too closely to shifting
architecture.  In particular, the original HOWTO was aimed at pointing
experienced programmers in the right direction, not reading the code
to them.

Perhaps consider adding:

	Kernel Style
		Don't do it in the kernel
		Don't sprinkle ifdefs
		User interfaces: read/write better than ioctls
		Architecture specific code & portability
		GNU extensions

	Kernel Politics:
		Licencing
		How to get a patch in
		Who owns what code?

Hope that helps,
Rusty.
--
Premature optmztion is rt of all evl. --DK

Re: suggestions for new kernel hacking-HOWTO

[Andreas Dilger]

On Aug 23, 2001  22:29 +0100, Andrew Ebling wrote:
> - How do I... ?
>         - Print messages to kernel logs
>         - create a new module
>         - Add a system call
>         - write ioctls
>         - Add a /proc entry
>         - Write a driver for a new device
>         - Add an option to the kernel configuation

Be sure to add notes about why NOT to add new system calls, ioctls, /proc
entries, etc.  It seems that the popular way to communicate to the kernel
these days is to be able to read/write data to the kernel device driver
via opening a device, or exporting a pseudo filesystem with information.

> I'm interested in hearing from seasoned kernel hackers (on what
> should/shouldn't go in this HOWTO) and newbies (what is particularly
> puzzling or not clear when setting out), hence the cross posting of this
> message.

Check out kernelnewbies.org as well, no point in re-inventing the wheel.

Cheers, Andreas
-- 
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/