From owner-freebsd-arch Wed Jan 30 2: 5:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 373D137B404 for ; Wed, 30 Jan 2002 02:05:34 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g0UA5ND82916; Wed, 30 Jan 2002 10:05:23 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.org (greenpeace [192.168.42.2]) by gratis.grondar.org (Postfix) with ESMTP id 965CE71; Wed, 30 Jan 2002 10:00:16 +0000 (GMT) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.org (8.11.6/8.11.6) with ESMTP id g0UA0GE33997; Wed, 30 Jan 2002 10:00:16 GMT (envelope-from mark@grondar.za) Message-Id: <200201301000.g0UA0GE33997@greenpeace.grondar.org> To: Dallas De Atley , arch@FreeBSD.ORG Subject: Re: __P macro question References: <3C57BED2.E1144F41@mindspring.com> In-Reply-To: <3C57BED2.E1144F41@mindspring.com> ; from Terry Lambert "Wed, 30 Jan 2002 01:37:22 PST." Date: Wed, 30 Jan 2002 10:00:11 +0000 From: Mark Murray 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 Said Terry Lambert : > You mean like when I compile "grep" and other command line tools > on my Amiga using Manx Aztec C, a K&R compiler? Yes. Except with those ancient compilers, you use KNRify or deprotoize, or one of a zillion tools to make ANSI code compliable on an antique compiler. > Or when I use Watcom to take some FreeBSD code for a POS system > to do the same thing for DR-DOS, because GCC won't run there > because it can't be compiled to use overlays? See above. > Really, if someone can't understand __P(), they should probably > not be in the kernel, with all those "dangerous" linker sets > and other less obvious code than __P()... Non sequitur. > > If the answer is "no", and I think it quite reasonably might be, then > > we can move forward with at least one assumption and that's that __P() > > can die in FreeBSD as something which merely obfuscates and renders > > our code more unpleasant to the eye. > > I think that portability of code between FreeBSD and OpenBSD > and NetBSD is a concern, and I think increasing the diffs > gratuitously between these systems is a Bad Idea(tm). Read their commit messages some time. They are slowly ansifying. > Also, as has already been raised, there is an issue of doing > back-ports of the code to FreeBSD X.Y, where X.Y is and of > the versions prior to the cosmetic make-over. Doing it properly will reduce the impact of this. > When NetBSD or OpenBSD gets new code (e.g. the SYN cache code > or the ipfilter license-inspired replacement), it would be > nice if porting the code would not require a human going > through and deciding which differences are there because they > need to be there, and which ones are there because of > gratuitous cosmetic changes. Terry - sooner or later a human has to look at the code to figure out which changes are needed. It happens. > > If you want my vote, and you get it whether that's the case or not, I > > say we nuke __P() from orbit until it and the unlucky disk platters it > > formerly rested on are reduced to a molten, bubbly, radioactive slag > > with the merest hint of ferrous particles still coating the surface. > > Can you get BSDI, NetBSD, and OpenBSD to go along with this? NetBSD and OpenBSD are already there AFAICT. (Not finished, but doing it) M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message