stripping off "xf86-*-" from drivers

[Xavier Bestel]

On Sun, 2008-01-20 at 23:37 -0800, David Miller wrote:
> From: Matthieu Herrb <matthieu.herrb at laas.fr>
> Date: Mon, 21 Jan 2008 07:59:46 +0100
> 
> > 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.
> 
> It might be constructive to investigate why it is that the embedded
> folks have this issue with "keeping up with the Jones's" in the
> kernel.
> 
> You might actually find that the real issue is that they make zero
> real effort to merge their work upstream even if they opensource
> everything they write for the kernel.

I have been working on embedded systems in the past, and that is all too
true. We just took the current kernel snapshot, ported it to our
platform and bugfixed from there on. We never merged code (in one
direction or the other). At one time I decided we should do something,
but we added so many third-party proprietary code to the mix that
sorting the mess and isolating patches was too time-consuming to be
doable.
Yes, what we didn't wasn't really legal, but you will find many of those
small companies do exactly that, more by ignorance than by malice.

> So instead of having the community help maintain their stuff alongside
> them, making going to future versions next to painless, they instead
> bear the brunt of all the work and pain assosciated with such.
> 
> It isn't because interfaces are breaking all the time.
> 
> If they merged their stuff upstream, all the little worker ants
> watching over the tree for build regressions would fix things up for
> them, gradually, as interface changes go into upstream.
> 
> This is purely the reason for their pain.  Merging their stuff
> upstream solves the update issue in two dimensions: 1) it offshores
> the work of ABI updates to the upstream folks making those ABI changes
> and 2) the update work is done smoothly, gradually, over time instead
> of all at once.
> 
> Yes, if you try to go from something like 2.6.18 to 2.6.24 all in one
> go you will have to make mountains of difficult changes to your
> drivers.  That's why you shouldn't approach the problem in that way.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>