On Fri, Sep 01, 2000 at 09:32:01AM -0700, Philip Brown wrote:
>[ Jeff Hartmann writes ]
>> > Which user-level card-specific dri modules are not going to barf if I
>> > initially dont support all the "special tweaks" at the kernel level?
>> Alot of these 'special tweaks' are so these cards can be operated in a
>> secure manner. Without this support these devices user level GL library
>> is useless.
>> We no longer have a 'device-independant' kernel module. Even the tdfx
>> card requires kernel support for mapping the areas of the device and for
>> the locking. However the tdfx driver doesn't have dma/interrupt
>> handlers/requirement of agpgart, so is easier to port.
>But you do have the makings of some level of abstraction, via the
>"drm.h" header file, and its list of ioctls.
>Assuming you guys WANT people to do more porting :-) can I strongly suggest
>1. You use this list of ioctls as the basis of a kernel/userspace
> API document. Doesnt have to be long. Just SOMETHING along the lines of
> "If you are writing the kernel drivers for a new architechture,
> you need to support all the IOCTLS listed"
>2. make drm.h a single unified file, with a minimum of #ifdefs where
> And a requirement for changes,
> "If you update this file, update the API doc FIRST!"
>Already, bsd/drm/kernel/dri.h and linux/drm/kernel/dri.h have minor
I've already made the change to share some files (like kernel/dri.h)
between bsd and linux in XFree86 4.0.1c (which will get folded into
the DRI CVS soon). This needs some more work, and ideally the files
that are largely OS-independent could be moved to somewhere more
>Its nice to have it visible in that directory, though. So maybe a softLINK
>to somewhere would be the nicest thing to do.
>[does cvs support links? if not, maybe an
> #include "../../shared/kernel/dri.h", and a comment]
CVS doesn't really do this, but it can easily be taken care of in the