From: Andrew Morton <akpm@osdl.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: paulmck@us.ibm.com, arjanv@redhat.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Non-GPL export of invalidate_mmap_range
Date: Wed, 18 Feb 2004 14:51:32 -0800 [thread overview]
Message-ID: <20040218145132.460214b5.akpm@osdl.org> (raw)
In-Reply-To: <20040218222138.A14585@infradead.org>
Christoph Hellwig <hch@infradead.org> wrote:
>
> I don't understand why IBM is pushing this dubious change right now,
It isn't a dubious change, on technical grounds. It is reasonable for a
distributed filesystem to want to be able to shoot down pte's which map
sections of pagecache. Just as it is reasonable for the filesystem to be
able to shoot down the pagecache itself.
We've exported much lower-level stuff than this, because some in-kernel
module happened to use it.
> GPL violation and thus copyright violation issues in Linux is the
> last thing IBM wants to see in the press with the current mess going
> on, right?
Well this is a chicken-and-egg, isn't it. The only way in which we can
audit the IBM code for its derivedness is for the source to be made
available. Although not necessarily under GPL. Or we accept Paul's claim,
which I personally am inclined to do.
Look, this isn't going anywhere. We have a perfectly reasonable request
from Paul to make this symbol available for IBM's filesystem. The usual
way to handle this sort of thing is to say "ooh. shit. hard." and not
reply to the email. That is not adequate and hopefully Paul will not let
us get away with it.
We need to give Paul a reasoned and logically consistent answer to his
request. For that we need to establish some sort of framework against
which to make a decision and then make the decision.
One approach is a fait-accomplis from the top-level maintainer. Here,
we're trying to do it in a different way.
I have proposed two criteria upon which this should be judged:
a) Does the export make technical sense? Do filesystems have
legitimate need for access to this symbol?
(really, a) is sufficient grounds, but for real-world reasons:)
b) Does the IBM filsystem meet the kernel's licensing requirements?
It appears that the answers are a): yes and b) probably.
Please, feel free to add additional criteria. We could also ask "do we
want to withhold this symbols to encourage IBM to GPL the filesystem" or
"do we simply refuse to export any symbol which is not used by any GPL
software" (if so, why?). Over to you.
But at the end of the day, if we decide to not export this symbol, we owe
Paul a good, solid reason, yes?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-02-18 22:51 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-16 19:09 Paul E. McKenney
2004-02-17 2:31 ` Andrew Morton
2004-02-17 7:35 ` Christoph Hellwig
2004-02-17 12:40 ` Paul E. McKenney
2004-02-18 0:19 ` Andrew Morton
2004-02-18 12:51 ` Arjan van de Ven
2004-02-18 14:00 ` Paul E. McKenney
2004-02-18 21:10 ` Christoph Hellwig
2004-02-18 15:06 ` Paul E. McKenney
2004-02-18 22:21 ` Christoph Hellwig
2004-02-18 22:51 ` Andrew Morton [this message]
2004-02-18 23:00 ` Christoph Hellwig
2004-02-18 16:21 ` Paul E. McKenney
2004-02-18 23:32 ` Andrew Morton
2004-02-19 12:32 ` Christoph Hellwig
2004-02-19 18:56 ` Andrew Morton
2004-02-19 19:01 ` Christoph Hellwig
2004-02-19 13:04 ` Paul E. McKenney
2004-02-20 3:17 ` Anton Blanchard
2004-02-20 21:46 ` Valdis.Kletnieks
2004-02-19 0:28 ` Andrew Morton
2004-02-18 18:36 ` Paul E. McKenney
2004-02-19 12:31 ` Christoph Hellwig
2004-02-19 9:11 ` Paul E. McKenney
2004-02-19 18:32 ` Lars Marowsky-Bree
2004-02-19 18:38 ` Arjan van de Ven
2004-02-19 19:16 ` viro
2004-02-19 16:15 ` Paul E. McKenney
2004-02-19 18:59 ` Tim Bird
2004-02-20 1:27 ` David Schwartz
2004-02-19 9:11 ` David Weinehall
2004-02-19 8:58 ` Paul E. McKenney
2004-03-04 5:51 ` Mike Fedyk
2004-02-19 10:29 ` Lars Marowsky-Bree
2004-02-19 9:00 ` Paul E. McKenney
2004-02-19 11:11 ` Arjan van de Ven
2004-02-19 11:53 ` Lars Marowsky-Bree
2004-02-18 18:04 ` Tim Bird
2004-02-19 20:56 ` Daniel Phillips
2004-02-19 22:06 ` Stephen C. Tweedie
2004-02-19 22:31 ` Daniel Phillips
2004-02-19 16:42 ` Paul E. McKenney
2004-02-20 2:06 ` Daniel Phillips
2004-02-19 19:47 ` Paul E. McKenney
2004-02-20 5:07 ` Daniel Phillips
2004-02-20 12:02 ` Paul E. McKenney
2004-02-20 20:37 ` Daniel Phillips
2004-02-20 14:01 ` Paul E. McKenney
2004-02-20 23:00 ` Daniel Phillips
2004-02-20 16:17 ` Paul E. McKenney
2004-02-21 3:19 ` Daniel Phillips
2004-02-21 19:00 ` Daniel Phillips
2004-02-22 23:39 ` Paul E. McKenney
2004-02-25 21:04 ` [RFC] Distributed mmap API Daniel Phillips
2004-02-25 19:12 ` Paul E. McKenney
2004-02-25 19:14 ` Paul E. McKenney
2004-02-25 22:07 ` Andrew Morton
2004-02-25 22:07 ` Daniel Phillips
2004-02-25 22:16 ` Andrew Morton
2004-02-25 22:46 ` Daniel Phillips
2004-03-03 3:00 ` Daniel Phillips
2004-03-03 3:15 ` Andrew Morton
2004-03-03 13:06 ` Daniel Phillips
2004-03-04 18:55 ` Paul E. McKenney
2004-02-20 21:17 ` Non-GPL export of invalidate_mmap_range Christoph Hellwig
2004-02-20 22:16 ` Daniel Phillips
2004-02-18 12:12 ` Dominik Kubla
2004-02-17 22:22 ` David Weinehall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040218145132.460214b5.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=arjanv@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paulmck@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox