This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Flatten sysdeps/unix/bsd/bsd4.4 into sysdeps/unix/bsd
On Mon, 21 May 2012, Roland McGrath wrote:
> > Likewise questions such as "What goes in sysdeps/gnu?".
>
> That one is easier, because it was created with a particular purpose in
> mind, and perhaps has not really diverged from the original intent. It's
> for things that are common to both GNU/Linux and GNU/Hurd. Particularly
> for things that also differ from BSD, since Hurd otherwise inherits from
> BSD directories. But also where it didn't seem appropriate to put
> something in sysdeps/generic.
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.
But there are only a few things in there. The errlist (and siglist) code
would seem reasonable enough for any system. _G_config.h and glob64.c
look quite generic. 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. 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. 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.
> "incremental cleanups" are good. My objection here is that you proposed
> a change that is not a cleanup as things stand today. It breaks Hurd.
> You proposed redressing that breakage by copying files, which makes the
> proposal fail to qualify as "cleanup" and thus my objection to that
> stands. I am thoroughly in favor of the overall efforts you have
You can actually do it by moving files (not copying): move the two files
in question from sysdeps/mach/ to sysdeps/mach/hurd/.
> undertaken to do incremental cleanup for these goals, but the specifics
> must be restricted to things that don't break builds and don't make
> things less clean in other regards.
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?
Given the complexity of the present state, I'm happy with things being a
clear improvement in overall cleanliness of the tree - I think moving lots
of files to a better location, with a couple of files needing to move to a
less good location as a side effect, makes sense as an intermediate step
in improving things.
I think the logical next step after eliminating the bsd4.4 directory level
would be to look closely at the files in the unified sysdeps/unix/bsd,
with reference to kFreeBSD patches, to work out to what extent the "bsd"
notion is still relevant. (If a file in "bsd" is not used on kFreeBSD,
likely "bsd" is not a very good place for it. If it's used there, but
also via #include with Linux, maybe it's really generic "unix" - or
"syscalls" or "ioctl" in a new scheme.)
Some files are simply of the form "implement function X in terms of
function Y". I wonder if rather than the ordered sysdeps directories
being used to find such files, it would be good for a new scheme to allow
a system to declare its use of individual files rather than a whole
directory containing them.
--
Joseph S. Myers
joseph@codesourcery.com