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

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

> 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.

These efforts have been quite useful in that regard.  The effort on bsd4.4
was indeed useful even though we can't put the change in yet.  Between you
and Thomas, we now know what the issues are and we can keep them in mind
when considering how to revamp the sysdeps selection scheme.

> 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.  

Agreed.

> 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.

> 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 
> at present.

I think there is universal agreement that the current sysdeps selection
scheme is incomprehensible.  I also think there is great consensus that
"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
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.


Thanks,
Roland