This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]