> here are further patches for X. I grep'd for linux and checked if all
> places that also apply to the Hurd include __GNU__, too. There are some
> places I didn't understand, and I welcome any help with them. I would
> also appreciate it if someone could revise my changes. Here are my notes,
> and attached is a diff.
As a general rule, the same feature selections appropriate for Linux/glibc
are probably the right choices for the Hurd. As always, using #ifdef __linux__
or #ifdef __GNU__ is the worst way to choose these things, but if that's
the norm in X then I suppose that is the thing to do. Many of these things
are just assuming real POSIX.1 conformance anyway.
I don't have the source on hand and haven't looked over your patches in
detail, so I'm some responding to your comments here.
> xdm/dm.h:
> setgroups arg type is gid_t, not int.
gid_t and int are the same size on the Hurd, so this is not a crucial issue
one way or the other in practice.
> xdm/daemon.c:
> xdm/util.c:
> xfs/os/daemon.c:
> Set setgrpg to setpgid.
Using setpgid is the right thing for any POSIX.1-1996 system.
> xdm/policy.c:
> How to get load average. TODO!!!
As of glibc-2.2, getloadavg will be included in libc, so that will be the
best thing to use on any glibc system.
> xdm/sessreg.c:
> Slot allocation. TODO!!!
I'm not sure what you mean exactly, but if this is utmp stuff then it
should use the glibc <utmp.h> or <utmpx.h> interfaces as on Linux.
> xinit/xinit.c:
> Some signal stuff? TODO!!!
>
> xsm/signals.c:
> Should we define USE_SYSV_SIGNALS? TODO!!!
The best signal interface to be using is POSIX.1 sigaction + SA_RESTART,
which is very consistent among the systems that support it at all.
At any rate, the details of the signals API should be the same for
Linux/glibc and Hurd/glibc.
> xterm/resize.c:
> We should probably define USE_TERMIOS et al. TODO!!!
Yes, POSIX termios is the interface to use on both Linux and Hurd.
> xfs/os/connection.c:
> xfs/os/utils.c:
> Xserver/os/utils.c:
> Include stdlib.h for random().
This is not Hurd-specific, just glibc-specific.
> Xserver/os/xalloc.c:
> can and should we use the linux i386 LOG_ALLOC? TODO!!!
I don't know what this means.
> For __GNU__, define HAVE_MMAP_ANON and include some stuff, including
> mach/vm_param.h for PAGE_SIZE.
Don't do that. Use `getpagesize ()' or `sysconf (_SC_PAGE_SIZE)'.
Never include any <mach/*> header without a very, very, very good reason.
Never include any <hurd/*> header without at least a pretty good reason.
> Xserver/xkb/ddxLoad.c:
> Include paths.h
>
> Xserver/Xprint/attributes.c:
> Define iswspace?
>
> Xserver/hw/xfree86/SuperProbe/Probe.c:
> Include string.h and don't define strchr strrchr
These are generic glibc issues.
> Xserver/Xprint/Init.c:
> Use lpc status instead lpstat -v.
This is a debian issue I guess, i.e. what printer system is going to be
installed.
> Xserver/hw/xfree86/accel/mach64/mach64init.c:
> Include mach/vm_param.h
No; see above. Is there a reason you need a compile-time constant page size?
> Xserver/hw/xfree86/common/xf86Beta.c:
> Activate SYSV and linux code section? TODO!!!
> Xserver/hw/xfree86/common/xf86Config.c:
> Here too (done).
> Xserver/hw/xfree86/accel/glint/vgaHW.c:
> Xserver/hw/xfree86/vga256/drivers/tdfx/vb_vgahw.c
> Define NEED_SAVED_CMAP as done fro MACH386 and linux?
> (Yes, as in Xserver/hw/xfree86/vga256/vga/vgaHW.c)
> Define bigger text amount as for Linux? TODO!!!
> (No? as in Xserver/hw/xfree86/vga256/vga/vgaHW.c)
> Xserver/hw/xfree86/accel/s3/s3ELSA.c:
> Xserver/hw/xfree86/accel/s3_virge/s3ELSA.c:
> Xserver/hw/xfree86/vga256/vga/vga.c:
> Xserver/hw/xfree86/vga256/drivers/s3_svga/s3ELSA.c:
> Do the same things as on linux?? TODO!!!
I'll have to look at the details, but I wouldn't worry about this part of
the code much until we really get other things in place for how we're going
to make the device access for the server work.
> .../AsmMacro.c: Prolly follow linux on cli sti?
I need the context.
> Xserver/hw/xfree86/accel/agx/agxInit.c:
> Use Mach code for priority, as seen in earlier example.
That appears also to be the BSD code; can you tell me what all would be
enabled if we defined `CSRG_BASED'? I can't see from the code what the
linux version does differently, so I don't know which interface is best.
Many things where you changed `#ifdef linux' into
`#if defined(linux) || defined(__GNU__)', I would argue
should instead be doing `#if __GLIBC__ - 0 >= 2' or something like that.
That is, these are generic glibc API issues and the test should be
appropriate for that. I don't know if the X people would dislike that
change more, but it's a better change.
