stripping off "xf86-*-" from drivers

[Matthias Hopf]

On Jan 24, 08 14:13:48 +0100, Jerome Glisse wrote:
> > 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.

Ok, point taken. ttm might be a reasonable hard API break point.
Many of the API breaks recently weren't IMHO.

> > Additionally, you realize, that even *that* isn't considered often ATM?
> > I mean just making sure that things work against head...
> 
> I do.

I never accused you. Just to make that clear :)

> 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.

That is IMHO a reasonable approach. So both kernel modules can live in
peace next to each other until one or the other is obsoleted.

> 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.

I admit that I do not understand why moving modesetting into kernel
space would change anything here. We can have a stable API for
modesetting in X as well.

> 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.

Definitely agreed.

> 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.

Which means abandoning the just recently achieved modularization and
making everything monolithic again?!?
I think the git submodule approach looks rather interesting, though I
have exactly zero experience in git submodules, I only know this concept
in SVN. I assume it's somewhat similar.

Matthias

-- 
Matthias Hopf <mhopf at suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de