stripping off "xf86-*-" from drivers

[Greg KH]

On Mon, Jan 21, 2008 at 07:59:46AM +0100, Matthieu Herrb wrote:
> Bernardo Innocenti wrote:
> > Luc Verhaegen wrote:
> > 
> >>> Even so, I really like Dave's idea.
> >> Why? Why can anyone agree with "Let's go monolithic again so that i 
> >> still do not have to bother in any way about being slightly backwards 
> >> compatible".
> > 
> > Because less backwards compatibility constraints result
> > in more useful development.
> 
> Or just more friendly to lazy developpers?
> 
> > 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
succeeds there is because the constant evolution of the kernel.  And
that constant evolution is allowed because of the way we treat internal
APIs.  If Linux is not allowed to evolve in such a manner, it will bloat
up HUGELY and start to die, just like Vista has proved, as well as
Solaris and AIX, and all other operating systems that have died in the
past.

And hey, x.org is is running on both of those platforms too, so there is
still hope :)

> I'm not convinced at all.

I'm sorry to hear that.  Do you have contrasting data that shows that I
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.

> I meet people who pester against the constant break in Linux drivers
> quite often. Especially in the domain of embedded systems, many projects
> use older versions of the kernel or glibc and are  really concerned by
> the difficulty for their projects to move forward, given the huge amount
> of incompatible changes they have to deal with.

The "embedded" world has been well know to totally ignore the kernel
development model and go off and do their own thing and then get burned
by it all the time.  That's their fault, not the Linux kernel
development model's fault.

> Incompatible changes from time to time are still ok but not if they can
> be avoided at a reasonable cost. And they should be clearly documented
> and announced in advance.

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.

thanks,

greg k-h