Re: [git pull] drm fixes

[Jerome Glisse]

On Fri, Mar 25, 2011 at 1:34 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
> On Fri, 25 Mar 2011 10:01:14 -0400
> Jerome Glisse <j.glisse@xxxxxxxxx> wrote:
>
>> On Fri, Mar 25, 2011 at 6:25 AM, Ben Skeggs <skeggsb@xxxxxxxxx> wrote:
>> > Oh, I wish this were actually the case.  The last time we attempted such a thing we were blasted by Linus.  It does make me wonder at why we're even bothering being in staging.
>> >
>> > This is where the binary drivers have a huge advantage, they package all the pieces of their driver together and can modify things as necessary.
>> >
>> > Part of me does think such an approach with the open source graphics drivers would be better.  The current model doesn't really fit too well in my opinion.  Though, admittedly, there's different problems to going other ways.
>> >
>> > Ben.
>>
>> Well i think being able to evolve the API would help a lot, it should
>> still be possible to keep supporting old API over a year or so. But my
>> feeling is some of the current API for some of the device, needs heavy
>> lifting if we ever want to improve things.
>
> Going back to the old model of a separate drm repo would create more
> problems than it solves, IMO.
>
> One thing I think Linus has been fairly consistent about is that making
> things easy for users (well at least power users who build their own
> kernels) is important.  That means ABIs need to be stable so that their
> existing userspace continues to work even after a kernel upgrade.
>
> If we went back to the old, out of tree model, we might be able to
> break things more easily (i.e. require lockstep upgrades of kernel &
> userspace when we change things, hopefully for a good reason), but I
> think end users would end up suffering.  They'd have to rely on their
> distro to pick up such changes and make sure dependencies were met and
> that upgrades/downgrades worked properly across the pre-packaged
> kernels that they made available.
>
> One of the main reasons we moved in-tree was to make sure our bits got
> into the hands of users more quickly, and to make life easier for the
> various downstream distros, not all of which have deep expertise in the
> graphics stack.
>
> Fortunately, neither of the issues that started this thread, the
> suspend/resume regression in i915 and the vblank ioctl enhancement, are
> problems in this respect.  The former is just a bug (though definitely
> not one that should have made it to Linus's tree) and the latter does
> preserve compatibility and fix a major issue, so isn't really a problem
> imo.
>
> But in the general sense, I think we just have to bite the bullet, take
> our time with ABI additions and changes so as to preserve compatibility
> for a long time (I think we've been doing well with this on the Intel
> side at least; we add feature flags every time we change something, and
> make sure userspace is forward and backward compatible).  This is more
> work for us, but I think it benefits the user in the end.  And it could
> be worse, at least we're not still dealing with memory layout
> compatibility between the DRM, fbdev, DDX and DRI drivers anymore!
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>

While for small change, slowly evolving the API is doable in backward
compatible way, major change are not. For instance if i were to write
radeon kms today i would drop the domain stuff out of the mix, would
not do the command submission the way they are and bunch of others
things that i have been meaning to try but have yet to prototype.
Change i am thinking about here means different userspace which would
communicate with kernel in a completely different way.

I am just acknowledging the fact that i did a bunch of very poor
decision in radeon kms and i feel that today i know better what would
be a good API but i can be wrong once again.

That aside, i would prefer if we stay upstream but if moving in our
own repo allow us to break API then i would jump in right away.

Note that when changing API one could keep old API with old code
around and just refuse to fix any issue with the old one, that means
some one updating kernel with something that worked will still have a
working configuration. If he then want to improve its graphics
experience he would have to update the userspace bits.

Cheers,
Jerome
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/