This is the mail archive of the
mailing list for the glibc project.
Re: Flatten sysdeps/unix/bsd/bsd4.4 into sysdeps/unix/bsd
On Thu, 17 May 2012, Roland McGrath wrote:
> We already have multiple motivations to thoroughly revamp the
> mechanism for sysdeps directory selection, as became clear with the
> x32 cases. I think it's quite clear that this is the direction we
> need to go, not more contortions and uglification to work around the
> difficult Implies nest we have to deal with today. We don't know at
> all yet exactly how it should be, but figuring that outis where the
> energy should go. It's not something to do lightly or quickly.
Among my motivations for this series of incremental sysdeps cleanups is to
help with this process - by clearing the undergrowth from the existing
directories, to make it easier for people to understand the present state
and what is actually used where.
We don't yet know exactly what divisions regarding "wordsize", or between
"ioctl" and "syscall" meaning of "unix", or things like that, may be most
useful in a new scheme; it makes sense to hold off on rearranging things
like that until more work has gone into understanding the various cases.
Likewise questions such as "What goes in sysdeps/gnu?".
But sometimes we can identify individual cleanups where current ports and
likely future ports do not need a file, so by removing the file we can
eliminate the question of "where does file X go in a new scheme" from what
people need to consider - or if a distinction between classes of systems X
and Y seems clearly irrelevant for current and likely future ports, again
eliminating it reduces the number of things people need to keep track of
in any future scheme.
I don't think we have enough people with a clear understanding of sysdeps
structures and how files are used across supported systems to be able to
have an in-depth discussion yet of how things should work. I don't know
if we can get to such a point, but I find eliminating unused files and
no-longer-useful distinctions between directories a significant help
myself in getting towards such an understanding (and discussions based on
common mainline sources more straightforward than discussions about
patches based on patches that are not in mainline).
Does anyone else wish to comment on how comprehensible or intuitive they
find the present sysdeps directory structures and ordering, and whether
they think incremental cleanups of files and subdirectory levels will make
it easier for them to understand the present arrangements as part of
contributing usefully towards the design of an improved system? For
myself I find it pretty much at or beyond the limits of comprehensibility
Joseph S. Myers