Let me see if I understand you correctly. Metrowerks (Motorola) makes a
twenty something million dollar investment in your little company, and as
part of the agreement (not to mention Metrowerk's sole motivation) you are
required to create a version of Linux that compiles under their ANSI c tool
chain. Furthermore, you are attempting to lobby the community into helping
your effort under the pretense that it is for the good of Linux? Survey
says...bzzzsst. Wrong answer Chuck, but for your consolation prize you get
your own non-standard, divergent Linux.
Thanks for playing!
Bryan
Tim Riker wrote:
All,
Alright, I've been lurking long enough on this thread. What say we
consider the option of building the kernel with a compiler other than
gcc? This would imply a slightly different structure to the makefiles
and code.
There are two immediate reasons I can come up with for this:
1. There are architectures where some other compiler may do better
optimizations than gcc. I will cite some examples here, no need to argue
out the point unless you disagree with the POSSIBILITY that this may be
true on at least one architecture. Anyway, possibilities include
Compaq's compiler on alpha, HP's compiler on hppa, Intel's compiler (or
rather plugins to another vendors compiler) on ia64, Metrowerk's
compiler on PPC, etc.
2. There are architectures where gcc is not yet available, but vendor C
compilers are.
I suggest that we avoid gcc extensions as much as possible, barring
performance hits. When there is an ANSI way of doing things we should
choose that route. Where there is not, then isolate the gcc way such
that compiler vendors can either:
1. implement the gcc way and conditional compile that code.
2. implement some other way and easily add that conditional code.
I've been looking into this here at Lineo for some of these vendors.
Here is a brief list of things I've come across:
1. C++ style comments
Occurs in over 4000 lines of source and header files. :-( Should be
converted to ansi c comments? We will probably want to just skirt this
issue for now as the next rev of ANSI C is likely to include ANSI C++
style comments.
2. Inline assembly statements
mostly in arch/ tree. Frequently used in macros as well. Much of this
will incur performance penalties if moved to external assembly files.
Some would require moving supported C code over as well. Hence many of
these will probably translate into conditional compilation based on the
compiler to avoid and performance hit for the mainstream case.
3. Declaring attributes of functions
The __attribute__ options: noreturn, const, format, section,
constructor, destructor, unused, and weak. weak and section are needed.
The rest can be ignored? These might want to be converted to #defines
such that alternative compilers can implement them differently.
4. Specifying attributes of variables
The __attribute__ options: aligned, packed, section and weak. As above
these will likely be #defines to handle different compiler syntax.
5. Conditionals with omitted operands
The missing operands should just be added into the mainstream source.
6. Referring to a type with typeof
no recommendation yet.
7. Macros with variable numbers of arguments
no recommendation yet.
8. Inquiring on alignment of types or variables (__alignof__)
no recommendation yet.
Well, I got a bit more long winded than I planned, but there it is.
Thoughts?
"H. Peter Anvin" wrote:
>
>Followup to: <[email protected]> By author: "David S.
>Miller" <[email protected]> In newsgroup: linux.dev.kernel > > We already
>know we are a bunch of pinheads wrt. the userland compiler > issue, full
>stop. It need not be restated several hundred more times. > Believe me,
>after such a large fiasco, we have listened :-) > > But, on the other hand,
>to say that "kgcc" comceptually is something > only Red Hat has ever done
>is a factual error, that is all I am trying > to state, nothing more. >
>
>I think at least supporting a "kgcc" compiler makes sense, conceptually
>(although it probably should have been called "kcc", but it's too late
>now.)
>
>The kernel uses a lot of gcc extensions, and history shows that these
>extensions aren't as stable as the compiler system as a whole.
>
>-hpa
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
Tim Riker <[email protected]> writes:
> I understand "will not", but "can not"? There is nothing stopping
> anyone, let's say SGI for example, from branching a separate gcc which
> would include copyrights assigned to FSF and other parties. Let's say
> this happens and a new sgigcc source base is created. Presumably then
> any defense of gcc code could be met with the argument that the code
> used came from sgigcc. This being the case what has the FSD gained by
> the current policy?
I'm unclear on how you're defining your terms, but were someone to have
violated the GPL license on gcc, I don't understand how the existence of
sgigcc would allow them to mount a defense. The point of the copyright
assignments is to make the copyright holder clear for legal purposes in
the event of an attempt to violate the license. You *seem* to be saying
that somehow one could claim that gcc code wasn't actually owned by the
FSF because it might have come from sgigcc (?), but of course that
wouldn't be the case because all gcc code has copyright assignments.
> I suppose that this is even the case today as one could argue that code
> came from intel-gcc if they used the Intel patches for ia64 or any other
> non-FSF copyrighted patches including patches made by the same company
> that the FSD might be in legal action with.
> In short, I do not see any enforceable advantages to the current FSF
> policies.
I can see a whole bunch of advantages, and I'm afraid that your paragraphs
above don't make any semantic sense to me. Could you please clarify what
you mean?
I think that the copyright assignment requirement is to some degree legal
paranoia; sure, it's not *necessary* under copyright law, and in theory
one could successfully defend the license without it. But I can also very
readily believe the advice of lawyers on the subject, namely that
enforcement of the copyright is significantly easier in real court if one
entity owns all of the rights.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
My understand of the argument for assigning all gcc copyright to the FSF
is that this make 'gcc' easier to defend. My example of an sgi-gcc shows
that sgi-gcc would have different criteria in a defense. This is solely
because both SGI and FSF would hold copyrights.
Now Marc Lehmann claims that this dual copyright code would be
"impossible" to defend. I merely pointed out that if that is truly the
case, gcc would also be indefensible because any GPL violator could
claim they took the source not from gcc, but from sgi-gcc which Marc
claims is indefensible.
I therefore assert that the fictitious sgi-gcc IS defensible and then by
conclusion that the current FSF position is not required to defend gcc
GPL. I am merely trying to assert what you stated as a given below:
> I think that the copyright assignment requirement is to some degree legal
> paranoia; sure, it's not *necessary* under copyright law, and in theory
> one could successfully defend the license without it. But I can also very
> readily believe the advice of lawyers on the subject, namely that
> enforcement of the copyright is significantly easier in real court if one
> entity owns all of the rights.
In short the impact of adding code to gcc that is not copyright FSF is
minimal. Only the FSF copyrighted code would be defensible by the FSF.
Any other code GPL violations would be the responsibility of the
copyright owners to defend.
As before IANAL. ;-)
Russ Allbery wrote:
>
> Tim Riker <[email protected]> writes:
>
> > I understand "will not", but "can not"? There is nothing stopping
> > anyone, let's say SGI for example, from branching a separate gcc which
> > would include copyrights assigned to FSF and other parties. Let's say
> > this happens and a new sgigcc source base is created. Presumably then
> > any defense of gcc code could be met with the argument that the code
> > used came from sgigcc. This being the case what has the FSD gained by
> > the current policy?
>
> I'm unclear on how you're defining your terms, but were someone to have
> violated the GPL license on gcc, I don't understand how the existence of
> sgigcc would allow them to mount a defense. The point of the copyright
> assignments is to make the copyright holder clear for legal purposes in
> the event of an attempt to violate the license. You *seem* to be saying
> that somehow one could claim that gcc code wasn't actually owned by the
> FSF because it might have come from sgigcc (?), but of course that
> wouldn't be the case because all gcc code has copyright assignments.
>
> > I suppose that this is even the case today as one could argue that code
> > came from intel-gcc if they used the Intel patches for ia64 or any other
> > non-FSF copyrighted patches including patches made by the same company
> > that the FSD might be in legal action with.
>
> > In short, I do not see any enforceable advantages to the current FSF
> > policies.
>
> I can see a whole bunch of advantages, and I'm afraid that your paragraphs
> above don't make any semantic sense to me. Could you please clarify what
> you mean?
>
>
> --
> Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
On Sun, Nov 05, 2000 at 06:01:29PM -0700, Tim Riker wrote:
> In short the impact of adding code to gcc that is not copyright FSF is
> minimal. Only the FSF copyrighted code would be defensible by the FSF. Any
> other code GPL violations would be the responsibility of the copyright
> owners to defend.
Just as a minor point: pro64 _does_ use GCC code. It's effectively the GCC
frontend stuck together with the SGI backend, with a translation layer in
the middle to translate between the intermediate code formats that the two
compilers use. There are some fairly entertaining "this is a gruesome hack"
comments in the source code.
--
Adam Sampson
[email protected]