linux-kernel - Re: Please release a stable kernel Linux 3.0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070627231212.GD21478@ftp.linux.org.uk>
Date:	Thu, 28 Jun 2007 00:12:12 +0100
From:	Al Viro <viro@....linux.org.uk>
To:	Al Boldi <a1426z@...ab.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Please release a stable kernel Linux 3.0

On Thu, Jun 28, 2007 at 01:32:23AM +0300, Al Boldi wrote:
> > > You are effectively inhibiting the development of an out-of-tree GPL
> > > module pool, by constantly pulling the rug under that community.
> >
> > The same thing happens with any yet-to-be-merged code.
> >
> > > Do you think this is fair?
> >
> > Yes, it is fair.  Decision to maintain your code out of tree indefinitely
> > is your decision.
> 
> It's not my decision, it's the kernel maintainers decision to reject 
> inclusion for one reason or another.  One reason could be a simple "we don't 
> think this is useful".

"I maintain a patch to $PROGRAM; maintainers of $PROGRAM don't think it's
useful; they should abstain from making changes that might require rewrite
of that patch".  Would you argue that this is fair?

BTW, "if it's GPLed, it's entitled to any internal function" is a shell game;
it tries to convert GPL-given right to get to those functions into some kind
of promise that those functions won't be changed.

EXPORT_SYMBOL_GPL() should've been EXPORT_SYMBOL_INTERNAL(); like it or not,
in-tree code *is* in different position exactly because it can be modified
by whoever makes a change affecting such code.  For in-tree module one
can expect such modifications to be done; for out-of-tree the same is
obviously not true, but conclusion is not "you can't do changes", it's
"authors of out-of-tree module get to do such modifications themselves".

Sure, there are subsets of exports that have stronger promise of not being
changed often; if a set of functions makes sense as an interface, it's
less likely to change than randomly selected function that just had an
export slapped on it at some point.  The promise is not absolute and it's
not based on some obligations to out-of-tree modules; it's simply a common
sense.

Again, most of the exports had been added with very little justification
at request of out-of-tree module authors.  That pile is many years past
the stage when it could be described as set of sane interfaces and it's
your [collective] fault.  Don't expect sympathy when you find the resulting
devalvation unpleasant to deal with...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/