Date: Wed, 30 Jan 2002 10:00:11 +0000 From: Mark Murray <mark@grondar.za> To: Dallas De Atley <deatley@apple.com>, arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <200201301000.g0UA0GE33997@greenpeace.grondar.org> In-Reply-To: <3C57BED2.E1144F41@mindspring.com> ; from Terry Lambert <tlambert2@mindspring.com> "Wed, 30 Jan 2002 01:37:22 PST." References: <3C57BED2.E1144F41@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Said Terry Lambert <tlambert2@mindspring.com>: > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201301000.g0UA0GE33997>