Stub sys/io.h?

[Mike Frysinger]

On Tue 15 Jul 2014 14:56:36 Carlos O'Donell wrote:
> 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?

i agree with this strongly having run into it a few times when porting 
packages to new arches
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20140802/652952ed/attachment.sig>