[Dri-devel] DRI on FreeBSD

[Doug R. <df...@ca...>]

Over the last few days, I have been porting the DRI to FreeBSD. I have
taken things to the stage of being able to run gears through DRI on a
voodoo3 board, which is pretty cool. If anyone is interested in taking a
look, I can generate patches to the sourceforge versions of xc and glide.
I haven't attempted to make any dma-based hardware to work yet and I'm
sure there will be problems there but not too many. I'll wait until there
is driver code for some kind of dma hardware which I have here before I
work on that.

While working through the code, I noticed a few issues with the way things
work.

In dma.c, while each buffer is being validated, the code checks to see if
buf->list != DRM_LIST_NONE. If not, it logs an error but doesn't return. I
think the kernel should return EINVAL at this point.

In auth.c, drm_remove_magic removes a drm_magic_entry_t from one of the
lists. The memory for the entry being removed doesn't get freed though
which looks like a memory leak. In addition, if the magic entry isn't
found and the code falls out of the loop, it looks like the code would end
up trying to call drm_free with a NULL pointer.

In drm.h, DRM_IOCTL_GET_MAGIC is declared as DRM_IOW(...). This ioctl
returns a value to userland (the magic number) (i.e. the user program is
reading data from the kernel). As such, the ioctl should be declared with
DRM_IOR(...). This isn't a problem on Linux since the driver does the
copyout itself but for FreeBSD, where the ioctl(2) syscall implementation
does the copyin/copyout on behalf of the driver, this means that the
client doesn't read the magic number and can't authenticate.

One goal for porting the DRI to FreeBSD is to allow Linux programs which
use DRI for rendering to work under FreeBSD's Linux emulation layer.  This
implies that a Linux version of GL should be able to work with a FreeBSD X
server and also under some circumstances that it should be possible to run
a Linux X server under FreeBSD.

This is perfectly reasonable since the ioctl based kernel api is clearly
defined and not OS-specific. The one problem is in the implementation of
drmOpen(). This uses /proc/graphics to discover the kernel module and to
communicate the name and BusID to clients. On FreeBSD, however, /proc is
only used to access process information and hasn't been misused to report
miscellaneous information to user programs. The FreeBSD method of
reporting this kind of information is via sysctl(2) which is how I have
implemented the FreeBSD kernel module.

Unfortunately, this means that a Linux implementation of drmOpenByName
will be very difficult to emulate under FreeBSD since it uses
"/proc/graphics/*/name" to find the right kernel device. I'm not sure what
to suggest here but if we could use an alternative method of implementing
drmOpenByName() and drmAvailable() which wasn't OS specific, it will be
much easier to run Linux binaries on non-Linux operating systems.

If we can find an OS-neutral way of implementing this part of the code,
all the user-side drm code will be OS-independant and the source can be
moved to an OS-neutral part of the source tree rather than duplicating
things in os-support/*/drm.

--
Doug Rabson				Mail:  df...@ca...
Technical Director, Qube Software Ltd.	Phone: +44 171 289 4201