>> 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!)
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
