On Sun, 10 Jun 2007, Paul Mackerras wrote:
> 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 fds will be out of POSIX definition in any case. They have to be
based at very high values in any case in order to be useful, and this
already breaks the POSIX definition of them.
> > 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.
You seem to deny the fact that libraries cannot reliably use fds allocated
by POSIX rules for internal communication with the kernel. I really don't
know what to say, if not that we must have a different definition of the
word "reliable".
Maybe if you go back in the thread and give your solutions, using POSIX
fds allocation semantics, to the problems that have been exposed, that
might help understanding.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
