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
| ||
|
Date: Mon, 15 Dec 2008 11:50:29 +1100 From: Paul Mackerras <paulus@...ba.org> To: Ingo Molnar <mingo@...e.hu> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>, eranian@...il.com, Vince Weaver <vince@...ter.net>, linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, Andrew Morton <akpm@...ux-foundation.org>, Eric Dumazet <dada1@...mosbay.com>, Robert Richter <robert.richter@....com>, Arjan van de Veen <arjan@...radead.org>, Peter Anvin <hpa@...or.com>, "David S. Miller" <davem@...emloft.net> Subject: Re: [patch] Performance Counters for Linux, v3 Ingo Molnar writes: > * Paul Mackerras <paulus@...ba.org> wrote: > > > Peter Zijlstra writes: > > > > > On Fri, 2008-12-12 at 18:42 +0100, stephane eranian wrote: > > > > In fact, I know tools which do not even need a library. > > > > > > By your own saying, the problem solved by libperfmon is a hard problem > > > (and I fully understand that). > > > > > > Now you say there is software out there that doesn't use libperfmon, > > > that means they'll have to duplicate that functionality. > > > > > > And only commercial software has a clear gain by wastefully duplicating > > > that effort. This means there is an active commercial interest to not > > > make perfmon the best technical solution there is, which is contrary to > > > the very thing Linux is about. > > > > > > What is worse, you defend that: > > > > > > > Go ask end-users what they think of that? > > > > > > > > You don't even need a library. All of this could be integrated into the tool. > > > > New processor, just go download the updated version of the tool. > > > > > > No! what people want is their problem fixed - no matter how. That is one > > > of the powers of FOSS, you can fix your problems in any way suitable. > > > > > > Would it not be much better if those folks duped into using a binary > > > only product only had to upgrade their FOSS kernel, instead of possibly > > > forking over more $$$ for an upgrade? > > > > > > You have just irrevocably proven to me this needs to go into the kernel, > > > as the design of perfmon is little more than a GPL circumvention device > > > - independent of whether you are aware of that or not. > > > > I'm sorry, but that is a pretty silly argument. > > > > By that logic, the kernel module loader should include an in-kernel copy > > of gcc and binutils, and the fact that it doesn't proves that the module > > loader is little more than a GPL circumvention device - independent of > > whether you are aware of that or not. 8-) > > i'm not sure how your example applies: the kernel module loader is not an > application that needs to be updated to new versions of syscalls. Nor is > it a needless duplication of infrastructure - it runs in a completely > different protection domain - just to name one of the key differences. Peter's argument was in essence that since using perfmon3 involves some userspace computation that can be done by proprietary software instead of a GPL'd library (libpfm), that makes perfmon3 a GPL-circumvention device. I was trying to point out that that argument is silly by applying it to the kernel module loader. There the userspace component is gcc and binutils, and the computation they do can be done alternatively by proprietary software such as icc or xlc. That of itself doesn't make the module loader a GPL-circumvention device (though it may be for other reasons). And if the argument is silly in that case (which it is), it is even more silly in the case of perfmon3, where what is being computed and passed to the kernel is just a few register values, not instructions. > Applications going to complex raw syscalls and avoiding a neutral hw > infrastructure library that implements a non-trivial job is quite typical > for FOSS-library-shy bin-only apps. The "you cannot infringe what you do > not link to at all" kind of defensive thinking. FOSS is about freedom - we don't force anyone to use our code. If someone wants to use their own code instead of glibc or libpfm on the user-space side of the syscall interface, that's fine. Paul. -- 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/
Powered by blists - more mailing lists