Dave Airlie writes:
> >
> > Looks like that Dave Airlie has pushed another set of patches
> > made by Paul Mackerras into the DRM code.
> > My patches support a wider range of chipsets (Matrox, R128 and Radeon)
> > and provide a framework which makes it easy to add ioctl32 support
> > to more chipsets.
> > Furthermore they have support for both the old style ioctl32 support
> > and the one that uses compat_alloc_user_space() so they should work
> > on a wider range of kernels.
>
> And this is probably all fine for DRM CVS or Xorg, but for the kernel it
> just isn't acceptable, I'd be flamed down if I pushed this patch kernel
> side, its just a fact of life... I would have to remove all the macros and
> old style ioctl32 stuff to get this into the kernel, without any way of
> testing it ... I'm not willing to do that, I'm going to port over the mga
> and r128 work you've done to Paul's scheme and push them kernel side ...
Dave, if you cannot test this why do you want to port my code
to Paul's sceme - which seems to be much more error prone than
using my sceme?
Ripping out the macros is easy to do. There are ifdefs that select
between them so the code can easily be identified. All that's left
to do will show up immediately when you do a compile.
Furthermore if you don't want to do it I would be willing to do that.
But I'm not going to remove all the macros as they are there for a
reason. Furthermore the DRM code contains a lot of other macros already
which have been accepted by the kernel folks.
Ripping out the old non-'compat_alloc_userspace()' sceme would
tremendously simplify the macros so I'd assume they will look much
more acceptable to kernel people.
Again, the macros are there to make adding ioctl32 support to other
drivers easy. I don't expect people will bother if it's a lot of
work, error prone if they don't even have a chance to test it.
>
> The changes to types need to clarify what exactly breaks where, I'm not as
> worried about the interactions between X and Mesa as I am about old
> Xs and new kernels... if we change the sarea size in X will it run on an
> old kernel, if I upgrade to a new kernel without changing X will it still
> work? I'm only taking care of the DRM, really the userspace stuff is going
> to have to be up to someone with more authority than me... (I've asked for
> people to review your patch when you first published it, no-one did..)
I've investigated this and I did not encounter a situation where anything
breaks.
I would certainly be able to push the X stuff. However since this is
dependent on the DRI bits it should be pushed toegther. I assume there
there is a scenario on how to do this, that's been used in the past.
Therefore I'm looking for someone who knows how this was done.
Maybe Alan can help me on this?
>
> Breakage in X-> DRI isn't so bad as a release will be consistent.. it'll
> just break ATI binary drivers...
>
No, it won't - as ATi needs to ship the DRI modules and the
X driver together anyhow.
Cheers,
Egbert.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
