Re: Development tree, PLEASE?

[Alistair John Strachan]

On Saturday 21 January 2006 09:22, Jan Engelhardt wrote:
> >> I'd say the kernel tries damn hard at maintaining backwards
> >> compatibility for userspace.
> >> It tries less hard, but still makes a pretty good effort, for internal
> >> APIs, but the real solution to the internal API churn is to get your
> >> code merged as it'll then get updated automagically whenever something
> >> changes - people who remove or change internals try very hard to also
> >> update all (in-tree) users of the old stuff - take a look at when I
> >> removed a small thing like verify_area() if you want an example.
> >
> > The only argument I have is one that won't fly at all here on LKML and
> > that's about all the corporate sponsors the LK has that are also doing
> > custom closed source modules that are only useful for their particular
> > hardware.
>
> It really does not fly. I run a "damn old" nvidia driver (1.0-4496)
> with a little portforward work on a 2.6.15. It is slowly ceasing to
> be perfect, but given that 4496 was originally only for 2.4, I'd say
> that's good news. (It was first portforwarded by sh.nu to 2.6.4 or so,
> until nvidia.com came up with 2.6 support on their own. I then took
> the sh.nu port and pf'ed it on my own, and until now, the only things
> that make slight gcc warnings are CONFIG_PM_LEGACY and the
> 4-level-pagetable stuff. I'd say the API is stable long enough!)

Myself and Christian Zander were the original authors of the port to 2.6, well 
before 2.6.0 was released. I think it's wrong to claim that the API changes 
between 2.4 and 2.6 were trivial or limited, we made a significant number of 
changes to the driver in almost every subsystem -- memory management, AGP 
handling, devfs support, module support, bh versus tasklets, etc..

Also if you look even today at Makefile.kbuild, there's quite a significant 
amount of work required to get it work with both 2.4 and 2.6 (the 2.6 code is 
obviously simpler). To top it off, supporting these "vendor kernels" 
mentioned in this thread also requires many pre-compilation checks.

I'm of the opinion that the kernel API should not be stable, but let's please 
not pretend that it is. That simply is not the case. For vendors, maintaining 
support for literally years of kernels is a challenge.

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/