http://undeadly.org/cgi?action=article&sid=20140719082410

Contributed by tbert on Sat Jul 19 08:24:01 2014 (GMT)
from the closing-holes-by-closing-apertures dept.

Jonathan Gray (jsg@) writes in to let us know why he spent 30 hours in coach to be with us:

> One of the first things I did at g2k14 was import the Mesa update I've been working on for some time now. I've been tracking the Mesa git for a few months and submitting patches to reduce the amount of pain involved and given the local diff isn't too large anymore it seemed like a decent time to update. Shortly before the hackathon I ran into a problem getting Mesa to build on i386 however. It turns out there is an i386 only codepath that does a sysctl to check if SSE is enabled. This turned out to be a problem because sysctl.h pulls in uvm_extern.h which then pulls in a bunch of kernel headers including mutex.h which meant that Mesa's mtx_init() collided with the kernel's mtx_init(). Theo spent some time cleaning up the sysctl and uvm headers so they wouldn't include anywhere near as many definitions, and that work had already been committed when I arrived at the hackathon.

> The following day I did some xenocara builds to try and catch any additional problems. The problem I found was due to a symlink in the Mesa dist file that cvs import ignores, which was fixed by pointing the Makefiles to a different directory. I also double checked that LLVM enabled Mesa builds worked still worked via the LLVMpipe software renderer. Another problem the Mesa builds showed is that sys.mk the Makefile that gets automatically included by make adds CFLAGS to CXXFLAGS. As Mesa is a mixture of C that assumes C99 and C++ code, g++ ends up complaining that it gets the C specific -std=c99 flag passed to it. A diff to correct this in the system Makefiles and a few other places will be mailed out in future.
>
> I also looked into getting the src tree to build with OPENSSL_NO_DEPRECATED defined which in most cases involved adding includes that are not automatically pulled in by other includes anymore. For some things like nginx that are externally maintained there are patches already available in future versions that we'll eventually pick up so it doesn't seem worthwhile patching our version just yet when there are still other places in the tree (libkeynote/bind/sendmail etc) that need changes made. I also had a quick look at compiling with OPENSSL_NO_SSL_INTERN but after seeing how dc and gzsig broke when building I decided to look elsewhere.
>
> I looked into updating some clang patches I've had lurking around for a few years and committed some things relating to that.
>
> Xorg can now run without having to grant userland direct access to a window of kernel/device memory if kernel modesetting (KMS) is supported. The problem being other devices still need access to this window to run Xorg. The installer asks a question if it finds a vga device that enables the window via the machdep.allowaperture sysctl. After a discussion with a few people at g2k14 I created some small scripts to extract PCI vendor/product numbers from the radeondrm and inteldrm drivers which are used by the pci attachment of the vga driver to print a line to dmesg if the window will be needed to run Xorg. The installer has been modified by halex@ and rpe@ to check for this line and will only ask if the person installing intends to run X11 (which enables the window) if it is found. The X11 question will not be asked on many servers now as there is a blacklist of graphics devices commonly found in servers in the code that decides whether the aperture is needed.
>
> A problem I've run into a few times now is the lack of a cpuid.h header which is provided by gcc >= 4.3 and clang to provide an interface to calling cpuid on i386 and amd64. Mesa git now requires cpuid.h to build. The Intel Xorg driver disables codepaths involved in deciding if SSE is present and making decisions based on cache sizes if it missing. And at least some ports (ie OpenXCOM) seem to expect it now. So I've taken the cpuid.h from clang to include in our version of GCC 4.2.1. Initially I changed the SSE_4_1 and SSE_4_2 definitions to SSE_41 and SSE42 to match the names used by GCC but likely both definitions will be included when this gets committed.
>
> Many thanks to the OpenBSD Foundation and Mitja for making g2k14 possible.