stripping off "xf86-*-" from drivers

[Jerome Glisse]

On Wed, 2008-01-23 at 12:13 -0800, Greg KH wrote:
> 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

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

As i said in the other thread it's up to linux distribution to back
port things if they feel the need (basically their consumer ask for
it).

Cheers,
Jerome Glisse