Re: [PATCH] malloc: Run fork handler as late as possible [BZ #19431]

[Florian Weimer <fweimer at redhat dot com>]

On 04/12/2016 08:46 PM, Roland McGrath wrote:
> > > > Should this perhaps be malloc-internal.h to match libc-internal.h?
> > >
> > > We also have libio/libioP.h, and include/malloc.h.  But I think a
> > > separate header makes sense if its contents is truly internal.
> > >
> > > What are the preferences here?
> >
> > I think having an internal header is good, but I can't give a definitive
> > reply regarding what the project prefers.
>
> We have a clear preference for keeping internal things in internal headers.
> Some of the existing wrapper headers conflate pure wrapper issues (macro
> versions of things, hidden_proto, etc) with providing internal interfaces.
> But we want to avoid doing that in the future.  Cleaning up existing
> violations of this principle would certainly be welcome.

Great, so include/malloc.h is out, and malloc-private.h, 
malloc-internal.h and mallocP.h are still in the race. :)

Just to clarify, do you see a future where we have about five different 
headers per subsystem?

  A. the installed header, subsystem/subsystem.h
  B. its wrapper, include/subsystem.h
  C. architecture-specific overrides, subsystem/bits/subsystem.h,
     to be installed
  D. architecture-specific overrides, not installed
     (must not be in bits/ per previous discussion)
  E. a header for libc-internal access across subsystem boundaries,
     name undecided (often mixed into include/subsystem.h today,
     but libioP.h is an existing example for such a separate header)
  F. a header for subsystem-internal declarations shared by
     translation units in the subsystem, naming convention undecided
     (but there is precedent subsystem-private.h, e.g. pty-private.h)

The new header in this patch is in category F (used across subsystems, 
internal to libc).  Should we keep this separate from E and use a 
separate naming convention?

Florian