stripping off "xf86-*-" from drivers
mhopf at suse.de
Thu Jan 24 05:29:27 PST 2008
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
> 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
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 Hopf <mhopf at suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat at mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
More information about the xorg