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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
