From owner-freebsd-arch Wed Jan 30 20:24: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id BB1A837B429 for ; Wed, 30 Jan 2002 20:23:06 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id g0V4M4d68582; Wed, 30 Jan 2002 20:22:04 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Terry Lambert Cc: Peter Wemm , Garance A Drosihn , Alfred Perlstein , Poul-Henning Kamp , Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: Message from Terry Lambert of "Wed, 30 Jan 2002 19:40:02 PST." <3C58BC92.44F5ED37@mindspring.com> Date: Wed, 30 Jan 2002 20:22:04 -0800 Message-ID: <68578.1012450924@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Can you guys please remove Dallas from the CC line? I think this debate has long since ceased to have any relevance to him and he's probably just too polite to say anything. :-) > Peter Wemm wrote: > > > 1) You risk becoming the compiler maintainer for 2 > > > years, in order to comply with the license. > > > > Nope. Nobody says you have to maintain it. Besides, FreeBSD isn't going > > to run on any system so obscure that it wont have some sort of ansi > > compiler available any time in the forseeable future. > > Oops; three years, not two. Please read section 3(b) of the GPL > at: > > http://www.gnu.org/licenses/gpl.html > > > > 2) It is another barrier to using BSD code. > > > > So? > > So it is a barrier to contributing to a BSD project as a means > of promoting progress in the art and science, and, in general, > for betterment of the human condition. > > > versus what? GNU code which is also ANSI? > > Versus anything. The GNU code is already irrelevent, in that > it classifies some people as being less deserving than others, > and so it is not in the same category, since it has little or > no utility as a reference implementation for other than > interoperability testing. > > > > > 3) The GCC compiler is sub-par on many architectures. > > > > It tends to work better on older platforms than newer ones. > > How will this get the same P4 instruction pipelining optimization > performance that the native Intel supplied compiler has? > > > If eliminating the use of __P() in our code means that we dont need to spen d > > developer-weeks of time every 6 months, then it is damn well worth it. > > I don't understand this statement. I don't see how time is > being saved by having this discussion in the first place. > > > > > For example, taking the TCP/IP stack by itself, with all > > > the DOS attack hardening and other hardenening, and using > > > it in a system other than FreeBSD. > > > > I hope you noticed that all that code is nearly pure ANSI. > > Yes, I had noticed that the syncache code used unprotected > prototypes. This is not inconsistent with my first posting > in this thread, which noted the current stated FreeBSD policy > with regard to new code. > > > > *Bad* example! > > Your choice of the syncache/syncookie code was a bad example; > for the most part, it does not fall into the "hardeneing" > category. If you want to discuss the architectural issues > with this code, we should start a different thread. > > -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message