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:
Figure out whose pond you've been pissing in. Look at the top of
the source files, inside the MAINTAINERS
file, and last of all in the CREDITS
file.
You should coordinate with this person to make sure you're not
duplicating effort, or trying something that's already been
rejected.
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 they want to make a change.
Usually you want a configuration option for your kernel hack.
Edit Config.in
in the appropriate directory
(but under arch/
it's called
config.in
). 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
Config.in
files (see
Documentation/kbuild/kconfig-language.txt
).
It's good to run "make xconfig" at least once to test (because
it's the only one with a static parser).
Variables which can be Y or N use bool followed by a tagline and the config define name (which must start with CONFIG_). The tristate function is the same, but allows the answer M (which defines CONFIG_foo_MODULE in your source, instead of CONFIG_FOO) if CONFIG_MODULES is enabled.
You may well want to make your CONFIG option only visible if
CONFIG_EXPERIMENTAL is enabled: this serves as a
warning to users. There many other fancy things you can do: see
the various Config.in
files for ideas.
Edit the Makefile
: the CONFIG variables are
exported here so you can conditionalize compilation with `ifeq'.
If your file exports symbols then add the names to
export-objs
so that genksyms will find them.
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
EXPORT_SYMBOL()
statements to their own
object with a unique name.
This is why several systems have separate exporting objects,
usually suffixed with ksyms.
Document your option in Documentation/Configure.help. Mention incompatibilities and issues here. Definitely end your description with “ if in doubt, say N ” (or, occasionally, `Y'); this is for people who have no idea what you are talking about.
Put yourself in CREDITS
if you've done
something noteworthy, usually beyond a single file (your name
should be at the top of the source files anyway).
MAINTAINERS
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.
Finally, don't forget to read Documentation/SubmittingPatches
and possibly Documentation/SubmittingDrivers
.