Kernel inclusion policy, meta desicion making structure?

Kernel inclusion policy, meta desicion making structure?

[Tim Post]

Good day/evening to all.

I was wondering if a meta version of the decision making process that
would be employed to determine if a new contribution does or does not go
into the main stream Linux kernel.

The following abstract demonstrates my question if it does not make
sense:

"There are many file systems made for the Linux kernel. Only some of
them are present by default in released Kernels."

"There is an AoE block module in the Kernel, but not the userspace blade
module. Only one was included."

Does some document exist that shows the decision making process so that
I can easily answer the ultimate question of "Why not" for myself? It
would be fun to examine code until I could answer the question myself,
and very educational for me as a programmer. Once I figure it out, I
"own" just a little more knowledge without pestering you guys.

I would like to write my own lightweight cluster file system and make
modifications to existing cluster file systems. I think first I should
better learn in practice whats wrong with existing before I go improving
it :) This document would be the best starting point for me.

Thank you in advance for any links. My question is obscure and thus hard
to search for in the archives, I post only after doing so.

Best regards,
--Tim

Re: Kernel inclusion policy, meta desicion making structure?

[Stefan Richter]

Tim Post wrote on 2007-06-04:
> I was wondering if a meta version of the decision making process that
> would be employed to determine if a new contribution does or does not go
> into the main stream Linux kernel.
[...]
> Does some document exist that shows the decision making process so that
> I can easily answer the ultimate question of "Why not" for myself?

There is documentation on how submissions should look like.  Other than
that, these are case-by-case decisions based on a number of factors.
Perhaps you should look up discussions on merge requests (accepted as
well as rejected ones) in archives or better at sources like LWN.net.

[...]
> I would like to write my own lightweight cluster file system and make
> modifications to existing cluster file systems.

If you don't want to start with an actual submission, you could begin
with discussing the specific features you have in mind directly with the
developers and maintainers of the existing cluster FSs.  Then it should
become clearer how to proceed most effectively.
-- 
Stefan Richter
-=====-=-=== -==- ---=-
http://arcgraph.de/sr/

Re: Kernel inclusion policy, meta desicion making structure?

[Jesper Juhl]

On 06/06/07, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Tim Post wrote on 2007-06-04:
> > I was wondering if a meta version of the decision making process that
> > would be employed to determine if a new contribution does or does not go
> > into the main stream Linux kernel.
> [...]
> > Does some document exist that shows the decision making process so that
> > I can easily answer the ultimate question of "Why not" for myself?
>
> There is documentation on how submissions should look like.

Some starting points:

Documentation/HOWTO
Documentation/SubmittingDrivers
Documentation/SubmittingPatches
Documentation/SubmitChecklist
Documentation/ManagementStyle

> Other than
> that, these are case-by-case decisions based on a number of factors.
> Perhaps you should look up discussions on merge requests (accepted as
> well as rejected ones) in archives or better at sources like LWN.net.
>

Good LKML archives to search :

http://marc.info/?l=linux-kernel
http://lkml.org/

Sometimes good summaries of discussions / decision making processes
can also be found at http://kerneltrap.org/

You can also search the ChangeLog messages for different patches
easily via git-web:
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=summary

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html