-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jens Owen
Sent: Wednesday, March 27, 2002 6:23 AM
To: Alan Hourihane
Cc: dri-devel
Subject: Re: [Dri-devel] Restoring DRM Library Device Independence
Alan Hourihane wrote:
>
> On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote:
> > I've made some headway on this today, and could use some feedback based
> > on your BSD experience. I've attempted to move the packing of
> > drmRadeonInitCP into the 2D ddx driver, and the main concern I'm seeing
> > is the actual IOCTL request number. I can easily use the Linux number,
> > but I thought it might be better to have some OS independent offset.
> > However, generating all the combinations of _IO, _IOR, _IOW and _IOWR
> > semantics in an OS independent way is going to be challenging. See
> > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h:line
> > 373
> >
> > Here is an incomplete patch in case you are interested in the general
> > direction I was currently prototyping...
> >
> > Should I just use the Linux _IO* semantics and let other OS ports
> > twizzle this to get this working, or do you have any ideas on how we can
> > generate the proper semantics in a more general way. I think we will
> > need to generate these semantics at run time, not compile time.
> >
Heres just a thought...
When we added the usage of device specific ioctls we just linked them into
the drm library because that was convient at the time. I think keeping this
code os dependant is probably a good idea. This gives more flexibility, like
on another os where ioctl semantics are impossible. In such an os they
might want to use read/write to do message passing. In a clean
implementation of this case it won't even make sense to have a drmIOCTL at
all. Remember that each os can have their own drm library, even though I
think BSD basically uses the linux one. There really shouldn't be something
as os specific as an ioctl presented in the drm interface layer. It smells
of bad design.
The basic point of this exercise is to make it so we can hot swap driver
suites (or at least I'm pretty sure this is your goal.) Why don't we just
make each device have its own xfree module for its os specific part? That
way we can add/subtract/upgrade driver suites, and not upset the apple cart.
Just seems like a whole lot easier solution to the problem.
Adding another module load into each driver just sounds like a cleaner
implementation, and it solves your problem.
-Jeff
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
