Re: Linux 2.5.70

[Bill Davidsen (davidsen@tmr.com)]

On Wed, 28 May 2003, Linus Torvalds wrote:

> 
> On Wed, 28 May 2003, Bill Davidsen wrote:
> > 
> > Just the other day you posted strong opposition to breaking existing
> > binaries, how does that map with breaking existing hardware?
> 
> One fundamental difference is that I cannot fix it without people who
> _have_ the hardware caring. So if they don't care, I don't care. It's that
> easy. If you want to have your hardware supported, you need to help
> support it.

That's the case now, isn't it? unless the person with the non-working
hardware is willing and able to become the maintainer a lot of drivers
don't seem to get fixed. Unfortunately that the people with the old
hardware usually aren't developers.
> 
> Another difference is that it's better to not work at all, than to work
> incorrectly. So if your kernel doesn't boot or can't use your random piece
> of hardware, you just use an old kernel. But if everything looks normal,
> but some binary breaks in strange ways, that's _bad_.

Totally agree.
> 
> The latter reason is, btw, why we don't paper over the build failures like 
> some people suggested. If it hasn't been updated to the new interfaces, it 
> should preferably not even build: which is a big reason why we try to 
> rename interfaces when they change, exactly so that you don't get a subtly 
> broken build.

I don't think anyone suggested that, but there are a fair number of
drivers which could be fixed in minutes by someone who understands the new
interface. Replacing cli is easy, knowing what you replace it with is
something else again. There are new locks, per-cpu stuff added, lockless
methods... to do this right you have to do it often, and few users can do
more than give an error report which allows the problem to be reproduced.

-- 
bill davidsen <davidsen@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
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/