Hi Jerome,
Do you think your proposed change should also be applied to amdkfd's
IOCTLs ?
Oded
On 08/10/14 19:00, Jerome Glisse wrote:
> Hi,
>
> So if i do not start the discussion now it might be already too late. Given
> plan to converge open source driver and closed source driver to use a single
> common kernel driver and that this would be a new kernel driver. This is an
> opportunity to fix some of the radeon design issues (at least things that i
> would have done differently if only i could get some gas for my DeLorean).
>
> Among the thing that i will not do is the chunk stuff associated with cs
> ioctl. I find it ugly, if my memory serve me well i was trying to be future
> proof and allow the cs ioctl to be extended. While this original aim have
> been somewhat successfully, i think it was the wrong day to do it.
>
> My lastest (and what i still believe to be a good idea until proven wrong),
> is to change the way we do ioctl and use a little trick. This idea was also
> spark by the continuous additions we do to info ioctl which is getting ugly.
>
> So idea is simple, each ioctl would use some struct like :
>
> struct radeon_ioctl {
> u32 version;
> u32 size;
> };
>
> The version field is the key here, think of it as an index into an array of
> ioctl dispatch functions. So something like :
>
> struct radeon_ioctls {
> int (*iotcl)[MAX_IOCTL_NUM](void *data, ...);
> };
>
> struct radeon_ioctls rdispatch_ioctls[N];
>
> And now all ioctl go through this single entry point :
>
> int radeon_ioctl_stub(int ioctl, void *data, ...)
> {
> struct radeon_ioctl *rio = data;
>
> return rdispatch_ioctls[rio->version][ioctl](data, ...);
> }
>
> So this is rough idea but the point is that we can do proper ioctl versioning
> and have separate functions for each new versions and avoid ioctl cruft, or
> at least this is the theory.
>
> The two things this gave us, is feedback from userspace as we the version the
> kernel will know which version of userspace it is dealing with. The others one
> is that it does allow you to introduce a completely new API either for new
> generation of hardware or just as an evolution. And small bonus is that it
> does allow to slowly phase out API that we consider broken (ioctl per ioctl).
>
> So this is the main design change that i would do. I should probably rought
> up something that goes deeper for the cs ioctl.
>
> Cheers,
> Jérôme
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
