Re: Flatten sysdeps/unix/bsd/bsd4.4 into sysdeps/unix/bsd

[Roland McGrath <roland at hack dot frob dot com>]

> Given the name, I'd think it ought to be for things common to "GNU 
> systems" (as opposed to the GNU C Library on other systems), including 
> GNU/kFreeBSD.

Perhaps so.  IIRC the original case was the utmp structures, where what
matters is the file format to be used in the system's /var/run/utmp.
There we wanted GNU/Hurd and GNU/Linux to share, but BSD differed.

> The errlist (and siglist) code would seem reasonable enough for any
> system.

Only if a) all the errno names defined on that system are listed in
errno.texi and b) we want the errno.texi choice of the perror text
rather than matching some previous standard text for that system.

> _G_config.h and glob64.c look quite generic.  

I don't really know anything about those two cases.

> The various network code there is about use of some ioctls and associated
> structures - I don't know what BSDs may do there, but my natural
> inclination would be that in new arrangements they might go with other
> ioctl-based code; likewise sys/mtio.h.

AIUI the network code there is code that uses the same ioctl API on
GNU/Linux and GNU/Hurd (which has a Linux-derived IP implementation)
but a different ioctl API on BSDs.

> The unwind-resume.c / rt-unwind-resume.c would be generic to anything
> using the _Unwind_* interfaces, which is a lot more than just GNU systems
> - I'd think of those as generic by now.

I think the logic there was that these were really only needed for systems
that had a legacy of libc defining _Unwind_* interfaces.  In a wholly new
ABI, things could just be expected to have been linked against -lgcc_s
directly.

> And as for the utmp code, *something* has to be the default structure /
> interface definitions (unless you have a default header that just does
> #error) and I see no particular advantage in the default being the
> toplevel bits/utmp.h "Generic/BSDish" rather than the GNU version.

That one is indeed just how the history came about.  At the time, the
best-established libc configurations were ones running on BSDish systems.
It was quite some time later that we decided to switch GNU/Hurd to use
GNU/Linux-compatible utmp files instead of BSD-compatible ones.

> With the recent patch merges, are Hurd builds now substantially working 
> (or at least requiring many fewer than 86 topic branches) so patches 
> against current glibc can be readily tested there?

They are certainly better than they were before.  For a more concrete
answer, we'll need to hear from Thomas.

Regardless of the details, I don't think we should be doing anything
else very substantial in this area before 2.16.  (The .s elimination was
a good thing to do and I'd like to leave it at that.)  There's been
plenty of upheaval in this cycle already, and there isn't sufficient
bandwidth for any more without detracting attention from the work that's
more important to get done in 2.16.


Thanks,
Roland