Mikulas Patocka <[EMAIL PROTECTED]> writes:
> Imagine that there is specification of mark_buffer_dirty. That
> specification says that
> 1. it may not block
> 2. it may block
>
> In case 1. implementators wouldn't change it to block in stable kernel
> relese because they don't
Russell King wrote:
>
> Albert D. Cahalan writes:
> > The TCP maintainers do not seem to be sadistic bastards hell-bent on
> > breaking your drivers. API changes usually have a good reason.
>
> And when the API does change, like it has between Linux 2.2 and Linux 2.4,
> an email gets sent to thi
Albert D. Cahalan writes:
> The TCP maintainers do not seem to be sadistic bastards hell-bent on
> breaking your drivers. API changes usually have a good reason.
And when the API does change, like it has between Linux 2.2 and Linux 2.4,
an email gets sent to this list describing the change of API
> One of these things must happen:
>
> a. follow the specification, even if that makes code slow and contorted
> b. change the specification
> c. ignore the specification
> d. get rid of the specification
>
> Option "a" will not be accepted around here. Sorry.
It should be followed in stable re
Mikulas Patocka writes:
> Imagine that there is specification of mark_buffer_dirty. That
> specification says that
> 1. it may not block
> 2. it may block
>
> In case 1. implementators wouldn't change it to block in stable kernel
> relese because they don't want to violate the
5 matches
Mail list logo
