stripping off "xf86-*-" from drivers

[Jerome Glisse]

On Thu, 2008-01-24 at 12:59 +0100, Matthias Hopf wrote:
> On Jan 24, 08 02:32:57 +0100, Jerome Glisse wrote:
> > > am wrong?  If so, I would love to find it as this is something that I
> > > have been researching for many years now, and have not found any
> > > contrary evidence so far.
> 
> That, I agree. Hard evidence is really difficult to find.
> 
> > > If you want to start to achieve the change-rates that is going to allow
> > > x.org to succeed in the future, you have got to start getting over the
> > > "must be rigid and not change things" type mindset.  It is becomming
> > > more and more well known in the software-engineering industry that such
> > > proceedures just do not work out over the long period of time for
> > > systems that must constantly adapt to their changing environment.
> 
> I will not, ever, say anything against changing APIs. It's just that
> *typically* these changes can be made backwards compatible very easily.
> And if it is by bouncing the API version number.
> 
> It's totally up to the driver developer to either eat this dog food and
> have some #ifdef logic or API-version dependent code, or to not care
> about that and just support the latest stuff. It just shouldn't be made
> extra hard to support older API versions if it can be avoided.

When i was looking at ttm for radeon i wanted doing it in radeon
kernel module & ddx basing my work on what Dave started. I quickly
realized that this would be pain full and lead to barely understandable
code. Having ifdef all around or many different path just to support
older interface in driver lead to obfuscated code.

> > Thanks Greg to provide evidence that if we want to move a bit forward
> > we need to accept to loose backward compatibilities. Note that i am
> > not saying break the API or ABI at every commit but that whenever you
> > need to change them to move forward then just do and make sure that
> > things works against head but don't bother to try to find out how to
> > make things work with the previous release. And yes i am well aware
> 
> Sigh.
> Additionally, you realize, that even *that* isn't considered often ATM?
> I mean just making sure that things work against head...

I do.

> > that user want to have the lastest driver with their 2 years old
> > xserver, but i see no complaint at linux kernel for giving this
> > possibilities (at least so far no one did come up with data or
> > demonstration that the outcome will surpass the cost)...
> 
> AFAIK a 2 year old glibc still works with the newest kernel.
> 
> So even the kernel folks have stable APIs.

I am well aware of stable user space API kernel offer, this is
also one of the reason i started a new radeon kernel module so
i can get rid of current ioctl and simplify the code quite a lot.

> It just depends on whether we consider the driver API and internal one
> (that can be changed at will), or an external one.
> The X11 protocol is an external API, no matter what.
> AFAICS with splitting out the drivers from the Xserver we *agreed* that
> this is an external API. We also provide an SDK, another reason for
> seeing this as an agreed external API.
> 

This API things is also a reason which support my thinking that
kernel modesetting, ie having driver in kernel side, is what we
should do. We would expose a stable API but we are free to change
code inside kernel.

Note that the fact that we had drm, ddx, dri layer impair
development as this require you to be extra cautious about note
breaking relation between them thus making any fundamental
change harder. Killing the ddx layer will help, this is my feeling.

> This is my 2 cents. Mine. All mine.
> 
> Matthias

I can't agree more, we are all expressing personal opinion
and there is no clear cut as there is good & bad in each
positions.

My feeling is that we have been using current development
scheme for quite a long and this development scheme obviously
lead to problem in front of the current fundamental changes
we are making in the x stack (memory management, dri2, randr1.2,
input, ...) so maybe it's time to experiment others practice
which have been success full for other project like the linux
kernel.

Cheers,
Jerome Glisse