optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.

[Araneda, Dorian]

In reference to my last post i also came across this in 
the file Linux/include/asm-mips/string.h 
*
2  * This file is subject to the terms and conditions of the GNU General
Public
3  * License.  See the file "COPYING" in the main directory of this archive
4  * for more details.
5  *
6  * Copyright (c) 1994, 1995, 1996, 1997, 1998, 2001 Ralf Baechle
7  * Copyright (c) 2001 MIPS Technologies, Inc.
8  */
9 

I did not see an asm-i386  version. and some of the other platforms
had different headers.

this is why i believe linux kernel memcpy is GNU open source and 
could inadvertently cause a programer who wishes for thier code
to be independent and closed, to form a dependency to GNU open source.

please dont assume that i have something against GNU open source.
I think it is a great service to society.
But people should have a right to make a totatly independent
closed source program.

Now if i cant use gcc as suggested by an other person (again
in response to this thread) because
of GNU, I will have to present that issue to the intel lawers
to see if i need to start just compiling the closed source with the
intel compiler for linux.

-Dorian

-----Original Message-----
From: Andrew Pinski [mailto:pinskia@physics.uc.edu]
Sent: Tuesday, April 02, 2002 2:53 PM
To: Araneda, Dorian
Cc: 'Richard Henderson'; 'rth@gcc.gnu.org'; 'gcc-bugs@gcc.gnu.org';
'gcc-prs@gcc.gnu.org'; 'nobody@gcc.gnu.org'; 'gcc-gnats@gcc.gnu.org'
Subject: Re: optimization/3329: optimization large memory copies uses
kern el memcpy function without user's knowledge.


No the problem is that it requires a STD C library to compile C code and 
that is it.
IF memcpy is defined to be using the GNU licenses, this is wrong because 
it is part of the STD C (89 at least).


Thanks,
Andrew Pinski


On Tuesday, April 2, 2002, at 02:31 , Araneda, Dorian wrote:

> Mr. Henderson,
>
> I would expect such a response from a certain
> large Linux nemesis company that I will not name.
>
> 1. NO, you did not appear to understand what I was talking about or at
> least that's what it seemed like from your email.  And now,
> judging by the tone of your email, I suspect that you did not
> even care.
> your response:
> "    GCC requires that the memcpy symbol (among others) exist.
>     I believe you'll find that at some point the x86 Linux kernel
>     maintainers were convinced of this, and now that symbol does
>     exist to be exported to your module."
>
> is totally unrelated to my question.  I could care less about
> why the kernel exports a memcpy symbol and why it is  popular
> amongst the kernel developers.
>
> MY COMPLAINT IS:
> gcc adds OPEN SOURCE KERNEL DEPENDENT calls to my close
> source binary without me EXPLICITLY calling for it.
>
> your comment that Linux memcpy is not open source code is
> INCORRECT.  If closed source code has to depend on gnu open
> source code(linux memcpy), whether in binary form or not,
> the close source falls under the gnu license and must
> be distributed as gnu open source.
>
> IRREGARDLESS IF I AM RIGHT OR WRONG, I don't care to even give
> the chance of accidentally creating a dependency within our
> proprietary closed source code to gnu open source.
>
>
> the fact that I have to put:
>   #if defined(LINUX)
>   my_memcopy(&x, y, sizeof(x));
>   #else
>   x    = y;
>   #endif
>
> because of a gcc optimization
> is absurd.
>
> I sure hope you are not anyone important at redhat
> with that "So what, I have no sympathy" elitist
> attitude that you exhibited.  It shows poor character.
> And this is not the only time I have had the
> displeasure of dealing with arrogant people comming
> from redha.
>
> FYI: I have NEVER had this sort of experience with
> Mandrake or SuSE employees.
>
> I submitted this issue a year ago and had to
> hack my code to resolve it.  As far as I am
> concerned this issue OVER along with
> the FLAME thread you decided to initiate.
>
> -Dorian
>
>
>
> -----Original Message-----
> From: Richard Henderson [mailto:rth@redhat.com]
> Sent: Tuesday, April 02, 2002 1:18 PM
> To: Araneda, Dorian
> Cc: 'rth@gcc.gnu.org'; 'gcc-bugs@gcc.gnu.org'; 'gcc-prs@gcc.gnu.org';
> 'nobody@gcc.gnu.org'; 'gcc-gnats@gcc.gnu.org'
> Subject: Re: optimization/3329: optimization large memory copies uses
> kern el memcpy function without user's knowledge.
>
>
> On Tue, Apr 02, 2002 at 09:59:45AM -0800, Araneda, Dorian wrote:
>> I dont think you understand what i am talking about.
>
> I'm pretty sure I do.
>
>> The assembly output shows that memcopy is being used
>> when optimizations are turned on even a the minimum level.
>
> Yes.
>
>> The code above is a legitamate call which does not
>> need memcopy in place of optimized assembly code.
>
> "Need"?  Well, sure.  We could also expand printf inline
> every time we saw it, but we don't.  What we want is to
> generate efficient code, and that often involves this
> curious invention called "subroutines", particularly for
> larger, more complicated hunks of code.
>
>> This is not intuitive to the normal programmer.
>
> So?
>
>> I have no problem with memcopy being an exported kernel symbol.
>> Memcopy may be superduper wonderfuly optimized but I do not want
>> it or any other open source symbols in our closed source library.
>
> "memcpy" is hardly an "open source symbol".  It's an ISO C
> sanctioned library entry point.
>
> I have no sympathy.
>
>
> r~
>
>