<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML
><HEAD
><TITLE
>Putting Your Stuff in the Kernel</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="Unreliable Guide To Hacking The Linux Kernel"
HREF="book1.html"><LINK
REL="PREVIOUS"
TITLE="#if"
HREF="x469.html"><LINK
REL="NEXT"
TITLE="Kernel Cantrips"
HREF="c517.html"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Unreliable Guide To Hacking The Linux Kernel</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x469.html"
ACCESSKEY="P"
><<< Previous</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="c517.html"
ACCESSKEY="N"
>Next >>></A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="SUBMITTING"
></A
>Putting Your Stuff in the Kernel</H1
><P
> In order to get your stuff into shape for official inclusion, or
even to make a neat patch, there's administrative work to be
done:
</P
><P
></P
><UL
><LI
><P
> Figure out whose pond you've been pissing in. Look at the top of
the source files, inside the <TT
CLASS="FILENAME"
>MAINTAINERS</TT
>
file, and last of all in the <TT
CLASS="FILENAME"
>CREDITS</TT
> file.
You should coordinate with this person to make sure you're not
duplicating effort, or trying something that's already been
rejected.
</P
><P
> Make sure you put your name and EMail address at the top of
any files you create or mangle significantly. This is the
first place people will look when they find a bug, or when
<I
CLASS="EMPHASIS"
>they</I
> want to make a change.
</P
></LI
><LI
><P
> Usually you want a configuration option for your kernel hack.
Edit <TT
CLASS="FILENAME"
>Config.in</TT
> in the appropriate directory
(but under <TT
CLASS="FILENAME"
>arch/</TT
> it's called
<TT
CLASS="FILENAME"
>config.in</TT
>). The Config Language used is not
bash, even though it looks like bash; the safe way is to use only
the constructs that you already see in
<TT
CLASS="FILENAME"
>Config.in</TT
> files (see
<TT
CLASS="FILENAME"
>Documentation/kbuild/config-language.txt</TT
>).
It's good to run "make xconfig" at least once to test (because
it's the only one with a static parser).
</P
><P
> Variables which can be Y or N use <SPAN
CLASS="TYPE"
>bool</SPAN
> followed by a
tagline and the config define name (which must start with
CONFIG_). The <SPAN
CLASS="TYPE"
>tristate</SPAN
> function is the same, but
allows the answer M (which defines
<SPAN
CLASS="SYMBOL"
>CONFIG_foo_MODULE</SPAN
> in your source, instead of
<SPAN
CLASS="SYMBOL"
>CONFIG_FOO</SPAN
>) if <SPAN
CLASS="SYMBOL"
>CONFIG_MODULES</SPAN
>
is enabled.
</P
><P
> You may well want to make your CONFIG option only visible if
<SPAN
CLASS="SYMBOL"
>CONFIG_EXPERIMENTAL</SPAN
> is enabled: this serves as a
warning to users. There many other fancy things you can do: see
the various <TT
CLASS="FILENAME"
>Config.in</TT
> files for ideas.
</P
></LI
><LI
><P
> Edit the <TT
CLASS="FILENAME"
>Makefile</TT
>: the CONFIG variables are
exported here so you can conditionalize compilation with `ifeq'.
If your file exports symbols then add the names to
<TT
CLASS="VARNAME"
>export-objs</TT
> so that genksyms will find them.
<DIV
CLASS="CAUTION"
><P
></P
><TABLE
CLASS="CAUTION"
WIDTH="90%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="./stylesheet-images/caution.gif"
HSPACE="5"
ALT="Caution"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
> There is a restriction on the kernel build system that objects
which export symbols must have globally unique names.
If your object does not have a globally unique name then the
standard fix is to move the
<TT
CLASS="FUNCTION"
>EXPORT_SYMBOL()</TT
> statements to their own
object with a unique name.
This is why several systems have separate exporting objects,
usually suffixed with ksyms.
</P
></TD
></TR
></TABLE
></DIV
>
</P
></LI
><LI
><P
> Document your option in Documentation/Configure.help. Mention
incompatibilities and issues here. <I
CLASS="EMPHASIS"
> Definitely
</I
> end your description with <SPAN
CLASS="QUOTE"
>" if in doubt, say N
"</SPAN
> (or, occasionally, `Y'); this is for people who have no
idea what you are talking about.
</P
></LI
><LI
><P
> Put yourself in <TT
CLASS="FILENAME"
>CREDITS</TT
> if you've done
something noteworthy, usually beyond a single file (your name
should be at the top of the source files anyway).
<TT
CLASS="FILENAME"
>MAINTAINERS</TT
> means you want to be consulted
when changes are made to a subsystem, and hear about bugs; it
implies a more-than-passing commitment to some part of the code.
</P
></LI
><LI
><P
> Finally, don't forget to read <TT
CLASS="FILENAME"
>Documentation/SubmittingPatches</TT
>
and possibly <TT
CLASS="FILENAME"
>Documentation/SubmittingDrivers</TT
>.
</P
></LI
></UL
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x469.html"
ACCESSKEY="P"
><<< Previous</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="c517.html"
ACCESSKEY="N"
>Next >>></A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>#if</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Kernel Cantrips</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
