lkml.org 
[lkml]   [2007]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> > Generally, the goal is to get external modules included into the kernel.
> > [...] even though it might sound harsh breaking
> > external modules and thereby making people aware that their code should
> > get into the kernel is IMHO a positive point.
>
> This argument seems to start from the assumption that any externally
> maintained kernel code *can* get into the kernel, which doesn't stand
> up to reality. Once you admit that there is code which, for very good
> reasons, won't ever be accepted into the mainline kernel tree, what you
> are saying amounts to: "Code that isn't fit to be included in the
> mainline kernel isn't fit to exist at all."

What kind of code is not accepted into the mainline kernel tree for good
reasons? What are these reasons? What specific code are you talking
about?

I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things. If you know of any that are not on the list at:
http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
please feel free to add them, or email me with the needed information
and I will add them to the list.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-10-26 05:39    [W:0.298 / U:0.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site