> 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 specification.
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. The best you can
hope for is option "b". Since that is hard work (want to help?) we
often end up not using a specification... hopefully by just not
having one, instead of by ignoring one.
Not saying it doesn't suck to have things undocumented, but at least
you don't have to reverse-engineer a multi-megabyte binary kernel to
find out what is going on.
>> Anytime you change implementation, you gotta check all drivers that use
>> them. I know, I'm one of the grunts that does such reviews and changes.
>
> Anytime you change implementation of syscalls, you gotta check all
> applications that use them ;-) Luckily not - because there is
> specification and you can check that syscalls conform to the
> specification, not apps.
Syscalls are more stable, but they may be changed after many years
of a transition period. The C library hides some of this from users.
> Now implementators of TCP will say: that driver is buggy. Everybody should
> set state=TASK_RUNNING before calling schedule to yield the process.
>
> Implementators of driver will say: TCP is buggy - no one should call my
> driver in TASK_[UN]INTERRUPTIBLE state.
>
> Who is right? If there is no specification....
The driver is buggy, unless the TCP maintainer can be convinced
that TCP is buggy. TCP is a big chunk of code that most people use,
while the driver is not so huge or critical.
The TCP maintainers do not seem to be sadistic bastards hell-bent on
breaking your drivers. API changes usually have a good reason.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/