public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@hack.frob.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: <libc-ports@sourceware.org>
Subject: Re: Unused sys/ucontext.h files
Date: Tue, 28 Jan 2014 22:43:00 -0000	[thread overview]
Message-ID: <20140128224328.C579D74438@topped-with-meat.com> (raw)
In-Reply-To: Joseph S. Myers's message of  Wednesday, 22 January 2014 03:26:54 +0000 <Pine.LNX.4.64.1401220324460.25161@digraph.polyomino.org.uk>

Yes, the sysdeps/arm file will (probably) be used by the arm-nacl
configuration.

In general, I am against removing files of this category just because
they are not used by any current configuration.  That is, files that are
machine-specific and for a machine that has some configurations in
current use, but are OS-independent.  I put them in the same category as
the stub files, most of which are not used by any configuration that can
be built.  Stubs of function implementations provide the outline of the
API and a starting point for filling in actual implementations.
Similarly, pure machine-specific files provide at least the basics of
the machine-specific API that should make sense across all OS
configurations of libc for that machine.

As with the stub implementations, there is of course always the danger
of bit rot.  As much as possible, all of libc's APIs are meant to be
independent of the underlying operating system.  That being the case,
people making API changes should endeavor to notice all the different
implementations and update them consistently.  People will forget, some
changes will be untested, etc.  But we should still be striving to
consider OS independence issues in all of our API choices.  Any time
there is an API whose only implementations that exist in our sources are
for a particular operating system, there is a much increased risk that
future changes will introduce or further enshrine assumptions about the
underlying operating system that make it more difficult (or impossible)
to implement that API elsewhere later on.


Thanks,
Roland

      parent reply	other threads:[~2014-01-28 22:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22  3:27 Joseph S. Myers
2014-01-22  4:41 ` Mike Frysinger
2014-01-22 17:14   ` Joseph S. Myers
2014-01-22 20:40     ` Thomas Schwinge
2014-01-28 22:43 ` Roland McGrath [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140128224328.C579D74438@topped-with-meat.com \
    --to=roland@hack.frob.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-ports@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).