stripping off "xf86-*-" from drivers

[Matthias Hopf]

On Jan 24, 08 02:32:57 +0100, Jerome Glisse wrote:
> > > > It may seem counter-intuitive, but Linux breaks its ABI as
> > > > many times as the developers see fit, and *therefore* it
> > > > comes with the largest driver base of any existing OS.
> > > 
> > > Do you have specific data to show that there's a correlation between the
> > > two ?
> > 
> > I do.
> > 
> > Let's look at two data points:
> > 	60% of Motorola's cell phones shipping today run Linux kernels
> > 	75% of the TOP500 supercomputers run Linux kernels
> > 
> > two widly divergent markets, users, and hardware types.  Both are
> > running from the same exact kernel codebase.  The _only_ way that Linux

Greg, while this numbers are impressive, this does not necessarily
lead to the conclusions you have.

Have you ever seen SunOS or Solaris code? I have, and it is absolutely
no wonder to me why Linux is so much superior to these systems
quality-wise and driver-wise.

The development model had its share, sure, but what counts in the end is
code quality. We won't get perfect code in X by just changing the
development model...

Also, I'm still not convinced that API breakages are necessary THAT
consequently as it is lived in the kernel community in order to advance
technology in a reasonable pace.

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

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

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

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 is my 2 cents. Mine. All mine.

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