I think Roland's email was a little over-hasty, to be sure. Let's just not fret about one message that was over-hasty and import too much to it, ok?
As for the technical issue, Roland is mostly but not entirely right about what gnumach/include is for. It has both the interface files, and pseudo-clones of C library headers, which don't get installed because the C library has better versions. In that category are <sys/types.h>, <sys/time.h>, <sys/reboot.h>, <sys/ioctl.h>, <mach/mig_support.h>, <mach/mach_traps.h>, <mach/error.h>, and <alloca.h>, by my count. By putting such headers in gnumach/include, the relevant kernel code is easier to understand, because the user will expect that the file named <alloca.h> or <sys/types.h> does more or less what the normal C library file does, and calling those <kern/alloca.h> or <kern/types.h> would make the reader have to wonder or remember what they are. It would not be inappropriate to put <string.h> there too, since it serves the same sort of function. However, <printf.h> does not belong there, and belongs in whichever directory holds the relevant functions. Thomas
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
