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] [day] [month] [year] [list]

Message-Id: <200706281837.50917.a1426z@gawab.com>
Date:	Thu, 28 Jun 2007 18:37:50 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	Al Viro <viro@....linux.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Please release a stable kernel Linux 3.0

Al Viro wrote:
> 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?

No, that's not fair.  But, what's fair is to ask maintainers of $PROGRAM to 
be so kind and expose a stable API via some layer, which can be used to 
connect external patches which are considered not useful, in the hope that 
some day it may grow into something useful.

> 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...

Ok, so some people made a mistake, and now everybody has to suffer?

What we need is a solution.  What is your suggestion?

Would a stable API exposing wrapper module be feasible?


Thanks!

--
Al

-
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/