Messages in this thread | | | Subject | Re: IP changes in 2.3.4x make things wierd?t | Date | Tue, 22 Feb 2000 13:49:12 +0000 (GMT) | From | Alan Cox <> |
| |
> Someone mentioned that Solaris deals with dead NIS servers etc. > It would be interesting for someone to find out (with strace or > something similar) how they detect the NIS server being down, > I would not be surprised if they used a timeout mechanism of > some sort.
Trace any BSD box and you will find a connected UDP socket delivers ICMP errors to the app. Its been true for over 15 years. Its used by a lot of BSD apps and neither preaching nor sitting on #linux with your fingers in your ears going "NotListeningNotListening" loudly will change that. They use timeouts too but then fast error recovery occurs because icmps for host unreach (dead in arp cache) occur fast.
The only difference between the old Linux and BSD behaviour is that BSD does not return ICMP errors to an unconnected socket. We have supported that since 1.0 (config option) and 1.1 or so (socket option). Note we even support it in a sane back compatible fashion.
That is not to save IP_RECVERR and friends are not good ideas. But they need to be good ideas that default to 15 years of defacto standards behaviour.
You don't get to arbitarily re-invent unix apis, tough but true. Otherwise we could dispose of several useless calls like chdir that can be done in library space.
Ultimately you are punishing millions of working setups by forcing them to turn on a feature instead of providing an off switch to those who want to turn it off.
That isn't good release engineering, it isn't good support engineering, it isn't good design. Now how about putting the defaults back so that Linux 2.3 is binary compatible with Linux 2.2 and API compatible with the real world. Otherwise I can tell you for free what the most popular diff in 2.4.0ac1 will be.
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |