This is the mail archive of the 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: 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 

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

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