Re: eradicating out of tree modules (was: : Linux Security *Module* Framework)

On Sat, Oct 27, 2007 at 04:47:15PM +0200, Tilman Schmidt wrote:
Adrian Bunk schrieb:
On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
[...] 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?
- proprietary code

It's unclear whether distributing not GPL compatible modules is legal
at all.

We're neither talking about distribution nor legal aspects, but
about existence. But anyway, you seem to agree with me that there
are very good reasons for not including these in the kernel.

And they are definitely not "very good reasons" for doing anything in
the kernel.

There is a big difference between "not doing anything to help"
and "actively doing something to make life difficult for". The
former is undoubtedly legitimate. It's the latter we're
discussing here.

Justifying anything with code with not GPL compatible licences has zero
relevance here.

And there's value in making life harder for such modules with
questionable legality. As an example, consider people who experienced
crashes of "the Linux kernel" caused by some binary-only driver.
Not that uncommon e.g. with some graphics drivers.
This harms the reputation of Linux as being stable.

The solution is not to support proprietary drivers, the solution is to
get open source replacements.

...
- code conflicting with existing kernel structure or policy
- code in which the concerned subsystem maintainers see no benefit

Let's fix the problems, not work around them.

That's certainly better, but not always possible. Do you
agree with me that if it isn't, then that's a very good
reason for not including that code in the kernel?

No, it's still a reason for fixing the real problem.

There is a conflict between getting code included and ensuring some
minimum quality of the kernel, but in many cases we could try better.

Correct. Again, you appear to agree with my statement that
for some code there are very good reasons not to include it
in the kernel.

But this does not result in any obligation of supporting low quality
external code that destabilizes the kernel of people using it.

If it's low quality code doing something useful - well, how many hundred
people are on Greg's list only waiting for some driver they could write?

And when there's a good reason for a kernel policy, then code that
violates this policy is not a "very good reason" for anything.

- code which its author is unable and/or unwilling to convert to
kernel coding standards
- code whose author is unable and/or unwilling to defend it on LKML
...

That's their fault, and definitely not a "very good reason" for making
life easier for them.

Putting aside the fruitless question of whose fault it is,
is it a "very good reason" for actively making life more
difficult for them than it is already, eg. by gratuitiously
breaking interfaces they rely on for no other "very good
reason" than to discourage out-of-tree development? In other
words, do you think it benefits the Linux community if you
discourage those programmers you've already scared away from
submitting their code to the kernel from continuing their
work off-tree, too? In summary, do you think the world would
be a better place if all the existing out-of-tree modules
just ceased to exist, without any replacement?

With your "without any replacement" you needlessly excluded the
reasonable solution:

The solution is that someone other than the author either takes the
existing external code or rewrites it from scratch, submits it for
inclusion into the kernel, and maintains it there.

Let me repeat that Greg has said he has hundreds of volunteers for such
tasks.

T.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

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

Relevant Pages

  • Re: [Full-disclosure] Bigger burger roll needed
    ... There's no reason why input coming in from a web server ... I would strongly suggest the driver is incomplete. ... Many of the crashes which get down to the kernel only manage to do so ... thus my reference to design architecture. ...
    (Full-Disclosure)
  • Re: [PATCH] CodingStyle: add typedefs chapter
    ... The reason we have them for things like pte_t etc. is that there ... then by all means go ahead and use a typedef. ... New types which are identical to standard C99 types, ... covers RTL which is used frequently with assembly language in the kernel. ...
    (Linux-Kernel)
  • Re: Forth for Mac OS X Leopard (Intel) - what are the options?
    ... As I understand it even FreeBSD binaries are elf. ... If the .data section works for the kernel part of xina, ... The official way is to use linker scripts. ... For some reason a normal start address in linux32 is around ...
    (comp.lang.forth)
  • Re: SuSE: migrating tot linux software RAID?
    ... > third machine with a megaraid that crashed because of this kernel ... >> The reason that you had data loss at all... ... > I had backups and successfully restored the system after a full install. ...
    (alt.os.linux.suse)
  • eradicating out of tree modules (was: : Linux Security *Module* Framework)
    ... reasons, won't ever be accepted into the mainline kernel tree, what you ... "Code that isn't fit to be included in the ... violates this policy is not a "very good reason" for anything. ...
    (Linux-Kernel)