This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Stub sys/io.h?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 15 Jul 2014 14:56:36 -0400
- Subject: Re: Stub sys/io.h?
- Authentication-results: sourceware.org; auth=none
- References: <53C40B1D dot 7000002 at redhat dot com> <20140715182729 dot BEAB12C398F at topped-with-meat dot com>
On 07/15/2014 02:27 PM, Roland McGrath wrote:
> I think the historical rationale was that <sys/io.h> was an x86-specific
> API for something that didn't even have an analogue on other machines. So
> it was part of the Linux/x86-specific and Hurd/x86-specific APIs that does
> not exist at all for other configurations, rather than being part of the
> generic glibc API that gets stubs in a configuration that doesn't (or
> can't) implement something meaningful.
>
> The traditional interfaces (in*, out*) are ones that are more like
> intrinsics for special machine instructions (which is all they are on x86).
> They're not OS interfaces that have a mechanism to report failure. So this
> API seems like a really poor fit for the notion of having a generic API
> that could have a stub implementation.
It seems your suggested guidance is that a package failing to build is
the best possible outcome that you want to indicate the package should
be ported or added to a blacklist for your architecture?
If so, I tend to agree, and we can add it to the FAQ.
Cheers,
Carlos.