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, Thomas Schwinge wrote:
> Comparing to the ordering I posted in
> this will move sysdeps/unix/bsd (and Implies) at the place where
> sysdeps/unix/bsd/bsd4.4 is now. According to my review, this would cause
That certainly illustrates how our present Implies system is unfortunately
> conflicts for sys/reboot.h where sysdeps/unix/bsd/sys/reboot.h would then
> preferred over the current sysdeps/mach/sys/reboot.h, and for usleep,
> where sysdeps/unix/bsd/usleep.c would then preferred over the current
> sysdeps/mach/usleep.c. I have to leave, so unfortunately cannot analyze
> this further right now, but will do so in the next days.
For usleep.c, the usual practice would be to have a Hurd sysdeps file that
#includes the Mach one, to avoid the BSD one getting in the way. There
are plenty of existing such instances where sysdeps file A includes
sysdeps file C to avoid B which would otherwise take precedence (when I've
noticed cases in my cleanups that are no longer needed because I've
removed file B, I've also removed file A, but I haven't tried to look for
and remove unnecessary such files systematically).
For sys/reboot.h, as an installed header I think the usual practice would
be to put the Mach one in an earlier directory.
But I have a more general question. Exactly what files from anywhere
under sysdeps/unix does Hurd use at all via sysdeps directories and
Implies? Hurd doesn't use Unix syscalls, so anything based around them is
irrelevant. To what extent is anything involving ioctl relevant to Hurd?
I wonder if we'd get cleaner results if Hurd didn't use sysdeps/unix via
Implies at all, but just #included any particular files it has a use for,
and had copies of any unix/ installed headers used on Hurd (and had its
own Subdirs file including the contents of sysdeps/unix/Subdirs and
Joseph S. Myers