Re: [patch 7/8] fdmap v2 - implement sys_socket2

[Paul Mackerras <paulus@samba.org>]

Davide Libenzi writes:

> > Why must everything that makes things a bit simpler and more
> > predictable for application programmers be called a "mistake"?
> 
> Because if you give guarantees on something, ppl start using such 
> guarantee in the wrong way. Kyle's email summarizes it.

OK, my question/protest was a bit terse.

What I am objecting to is this idea that many kernel developers seem
to have, that if there is some aspect of the kernel/user API that
becomes a bit inconvenient for the kernel to implement, then we can
put the blame on the applications that rely on that aspect, call them
names such as "legacy", "abuser", "conceptually buggy", "broken",
etc., and ultimately justify breaking the ABI -- since it's only those
applications that we have demonised that will be affected, after all.

In a way your response quoted above illustrates this perfectly.  If we
give guarantees then people will start relying on them "in the wrong
way" -- meaning, in any way that later becomes inconvenient to us.
What next?  Shall we break the guarantee that when read() returns, the
data is already in the user's buffer?  I'm sure we could improve
performance if we didn't have to give that guarantee, and after all,
only old, broken, legacy, conceptually buggy programs would be abusing
the interface by relying on that. :)

> This should really be treated as an opaque handle, with no assumption on 
> its value.

No.  This is an assertion that you have just conjured up to suit
yourself, but it is wrong.  It does not reflect either historical UNIX
practice or what is specified in POSIX.  Application writers are
perfectly justified in relying on getting the lowest-numbered unused
file descriptor.

If you don't think we should be bound by POSIX, then you are perfectly
free to go off and write your own research kernel with whatever
interface you want, and no programs available to run on it. :)

Paul.