> 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.
>
> In case 2. implementators of ext2 wouldn't assume that it doesn't block
> even if it doesn't in current implementation.
Whenever the question has been asked the answer is always assume anything
in the kernel outside of the current function blocks.
> In both cases, the bug wouldn't be created.
Nope. It looks like someone made a mistake in ext2...
>
> 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.
Not normally. The rule is that syscall don't change period. The
internal kernel interface is different. It is allowed to change.
As for syscall changing auditing most apps did happen when the LFS
spec was put together. So you would have an implementation that would
keep most apps from failing on large files.
> > > Saying "code is the specification" is not good.
> >
> > I'm not arguing against documentation. That is dumb. But the code is
> > ALWAYS canonical. Not docs.
>
> Let's see:
> Who is right? If there is no specification....
Hmm. The developers should get together and pow wow when the problem
is noticed. When it is finally talked out about how it should happen
then the code should get fixed accordingly.
It isn't about right and wrong it is about working code. Not that
documenting things doesn't help. And 2.4 is going in that direction...
Eric
-
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/