Date: Mon, 13 Jan 2003 13:29:00 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Bruce Evans <bde@zeta.org.au>, Jake Burkholder <jake@locore.ca>, sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <3E232F9C.D323FF99@mindspring.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <floatingpoint.h> 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 <floatingpoint.h> 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 <floatingpoint.h> which is obsoleted, use <ieeefp.h> 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 <floatingpoint.h> 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-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E232F9C.D323FF99>