linux-kernel - Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

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]

Date:	Thu, 14 Dec 2006 10:51:57 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Chris Wedgwood <cw@...f.org>
cc:	Eric Sandeen <sandeen@...deen.net>,
	Christoph Hellwig <hch@...radead.org>,
	Jeff Garzik <jeff@...zik.org>, Greg KH <gregkh@...e.de>,
	Jonathan Corbet <corbet@....net>,
	Andrew Morton <akpm@...l.org>,
	Martin Bligh <mbligh@...igh.org>,
	"Michael K. Edwards" <medwards.linux@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
 for 2.6.19]

On Thu, 14 Dec 2006, Chris Wedgwood wrote:
> 
> Calling internal symbols _INTERNAL is confusing?

Well, I'm not sure the _INTERNAL name is all that much better than the 
_GPL one.

In many ways, the _GPL one describes the _effects_ better, and also points 
out the reason _why_ something is marked differently. Sure, it's marked 
becasue it's internal, but why is does that have to be pointed out at all? 
Why not use the same EXPORT_SYMBOL? The answer to that is the "GPL" part, 
ie the expectation that internal symbols are so internal that they have 
license effects.

And if you were an external vendor doing binary only modules, would you 
react to "internal"? It wouldn't have the same "oh, _that_ is what it is 
all about" thing, would it?

So I do agree that we have probably done a bad job of explaining why that 
_GPL thing makes sense, and what it means on a deeper level (the license 
thing is a very superficial thing, but its worth naming just because the 
superficial thing is also the biggest _impact_ - even if it may not be the 
underlying deeper _reason_ for it).

So which makes more sense from a naming standpoint: the superficial impact 
that is what _matters_ for people, or the more subtle issue that causes it 
to have that impact?

I think that question is what it boils down to, and at least personally, 
while I see both things as being worthwhile, I think the superficial thing 
is the one that needs pointing out, because it's the one that may change 
your behaviour (while the deeper _meaning_ is more of just an 
explanation).

But I don't personally care that deeply. I mostly care about the fact that 
changing the name now would just be inconvenient and unnecessary churn, 
and that's probably my biggest reason to not want to do it ;)

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