From owner-freebsd-sparc Mon Jan 13 13:34:24 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B354837B401; Mon, 13 Jan 2003 13:34:21 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20B8643F65; Mon, 13 Jan 2003 13:34:21 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0169.cvx21-bradley.dialup.earthlink.net ([209.179.192.169] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18YCA4-0007eT-00; Mon, 13 Jan 2003 13:30:25 -0800 Message-ID: <3E232F9C.D323FF99@mindspring.com> Date: Mon, 13 Jan 2003 13:29:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: Bruce Evans , Jake Burkholder , sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 References: <20030113034638.GA2310@dhcp01.pn.xcllnt.net> <20030113190710.I11541-100000@gamplex.bde.org> <20030113100558.GA3423@dhcp01.pn.xcllnt.net> <3E2324B0.585FD417@mindspring.com> <20030113210642.GB798@dhcp01.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a405c081f6ab1e353bb0283fdc7e23389b666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Marcel Moolenaar wrote: > Ok. I'm now going to throw (an interpretation of) your own words into > the mix and let you decide how you want to prioritize them. I *live* to be hung on my own petard... go for it! 8-). > You said that FreeBSD on different platforms should not cause variation in the > API or ABI. If having on sparc64 makes sense, then > having all kinds of proprietary OS quirks on platforms with proprietary > OSes also makes sense. This contradicts with the uniformity across > platforms. Either we present the FreeBSD ABI and API uniformly across > the supported platforms or we provide an uniform subset and allow > deviation for ease of porting but then also have to accept porting > across different FreeBSD implementations. OK. I understand the discrepancy here. I'm going to point out up front that /usr/include/floatingpoint.h is actually a symlink to /usr/include/machine/floatingpoint.h, so this argument doesn't apply in this case. But that doesn't invalidate your argument, so it still needs to be addressed. The answer is that there should be no variation among platforms at the API level, inasmuch as it's possible to not vary between them. Having on SPARC makes sense, in terms of being able to support a *legacy* interface for *legacy* code that needs it. Both uses of the word "legacy" are important here. I think that the header file should complain, during compilation, when it is used, e.g.: #warning "this file includes which is obsoleted, use instead" This doesn't contradict uniformity across platforms, per se, since the interface is deprecated. That said, it should be uniformly deprecated across platforms; here's why: When someone ports code from Solaris SPARC to FreeBSD SPARC, the resulting port should compile on FreeBSD Alpha, FreeBS IA64, and FreeBSD i386, without modifications, so long as the software uses published interfaces (any file in /usr/include, but not in machine/ or sys/). This is about setting up rules that result in more FreeBSD software for all versions of FreeBSD, not just for one, and not to discourage porting to FreeBSD. I don't think it's acceptable to have porting differences across implementations, if it can be helped. It sets a bad precedent. > I favor an uniform ABI/API if only to keep our ports meisters sane, I don't really care if they are sane, but I'd prefer it if they don't go postal on me. 8-) 8-). > but also because there's just too much difference that the existence > or non-existence of will not make a big difference > in porting SunOS/Solaris code. This is gut-feeling -- use salt... It is, I think, an interface that can be deprecatedm but not removed, at this point. Removal can wait for one minor release following the insertion of a compilation warning message (or however long it is we are going to have to keep living with it, because of the volume of legacy software that needs it (i.e. as long as we have to live with "values.h", I think, and as long as we lived with direct.h/dirent.h; I notice that direct.h is finally gone, now...). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message