This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Merge sysdeps/unix/inet into sysdeps/unix
On Tue, 24 Apr 2012, Roland McGrath wrote:
> I'd like to leave this consolidation out for now.
> Is it harming anything?
The general motivation for this series of cleanup patches is to make
sysdeps directory structures simpler, and more closely related to
classifications of present-day systems glibc might plausibly be used on
rather than the classifications that made sense when it was originally
written, so that it's easier for people to understand glibc's directory
structures and see where particular functions (etc.) are coming from. As
a secondary benefit it's possible that builds may speed up through having
fewer sysdeps directories - see David Miller's comments in
<http://sourceware.org/ml/libc-alpha/2012-03/msg00952.html> about
"thousands of prefix rules" - although this is not a primary motivation.
(Some sysdeps cleanups, e.g. if we end up splitting the notion of
"wordsize" into more than one concept to handle cases such as x32 better,
could well end up *increasing* the number of sysdeps directories, and I
wouldn't object to such a cleanup on the basis of possibly making builds
slower.)
So the value of any one patch in this series is quite low - there isn't
much harm from any one unused file or any one sysdeps directory that no
longer usefully distinguishes supported systems - it's the overall effect
of lots of patches that helps make the code easier to follow.
> I'm considering a new port where I haven't yet decided if the inet Subdirs
> will be in or out. I like having the option of using sysdeps/unix without
> implying all the inet support.
I admit I thought of this patch as conservative for keeping using the
Subdirs mechanism at all for these directories. It would seem quite
natural to me for all the directories in sysdeps/unix/Subdirs and
sysdeps/unix/inet/Subdirs to be built unconditionally, not listed in
Subdirs at all.
Mostly sysdeps directories are about *how* some functionality is
implemented rather than about *what* interfaces are provided. There are
some totally platform-specific interfaces - some Linux system calls for
which no stub returning ENOSYS is provided on non-Linux platforms, for
example - but for the most part the API doesn't depend on the platform and
functions that aren't implemented for a platform return ENOSYS there (and
autoconf knows about detecting such functions as not-present via
gnu/stubs.h).
Disabling network functionality would to me seem reasonable but orthogonal
to the configured set of sysdeps directories, so maybe most naturally
arranged in some way other than avoiding a sysdeps directory with Subdirs
pointing to those directories. I know Carlos has expressed an interest in
building glibc with features configured according to POSIX profiles, so
maybe he would have ideas here about the best implementation approaches.
Bug 13696, about disabling libc code that works with nscd, also seems
related to that general question of how to allow for builds selectively
disabling features.
--
Joseph S. Myers
joseph@codesourcery.com