>I think this would be very difficult. I don't believe any of the "core"
>kernel hackers have access to all the hardware that Linux supports, and
>hence they can't ensure that nothing gets broken. As has been pointed
You don't necessarily need to have access to all the hardware to ensure
that things don't get broken. I expect that in most cases where drivers
get broken due to changes in the kernel it will be changes to memory
management etc that cause the breakage. Some examples are set_bit() being
used in 2.0.x where test_and_set_bit() is used in 2.1.x and the new dcache
code in 2.1.x. The broken code that these changes cause can be fixed
without knowing anything much about hardware etc, you just need to know
what the kernel code does.
>out, it's better that things are left in a non-compiling state than being
>subtly broken. Hopefully the active maintainers of various sections of
I agree. However given a choice between:
1) Can't compile but no-one knows.
2) Can't compile but listed in a bug database and we know when it broke.
3) Compiles but doesn't work.
I'd choose option 2.
Russell Coker