From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17152 invoked by alias); 27 Sep 2009 22:06:30 -0000 Received: (qmail 17142 invoked by uid 22791); 27 Sep 2009 22:06:29 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 27 Sep 2009 22:06:25 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id n8RM6N414853; Sun, 27 Sep 2009 23:06:23 +0100 (BST) Received: from [172.31.1.126] (neelix.jifvik.org [172.31.1.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id 9DD9F3FEB; Sun, 27 Sep 2009 23:06:22 +0100 (BST) Message-ID: <4ABFE1DD.8060604@jifvik.org> Date: Sun, 27 Sep 2009 22:06:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) MIME-Version: 1.0 To: Grant Edwards Cc: eCos discussion References: <6afa98b0909240334i7536f39drfce21817f2fe686c@mail.gmail.com> <4ABB9D9D.3080309@jifvik.org> <4ABC0AA4.4040208@jifvik.org> <4ABCC25B.8000009@jifvik.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Re: connect ethernet cable at run-time X-SW-Source: 2009-09/txt/msg00254.txt.bz2 Grant Edwards wrote: > On 2009-09-25, Jonathan Larmour wrote: >>But yes that does confirm that an unplugged cable at startup >>means no IP address unless the user calls >>init_all_network_interfaces again. >> >>In this respect, the DHCP code wants improvement. > > > I can't think of any use-cases for our products where the DHCP > client should ever give up. Telling customers they have to > guarantee the power-up sequence of various portions of their > plant to make our DHCP client happy isn't really an option. ;) > > Am I missing something? Are there situations where giving up > on acquiring an address is the right thing to do? On reflection, I think the choice may well have been intentional - simply a case of saying "let the user decide" (where user==eCos user). It may not be relevant to retry - maybe something else should be done instead. The init_all_network_interfaces() call is meant to be idempotent, so I think all you're meant to do is pretty much what Laurie is doing and call it periodically, if that's what you need. I don't believe you even need to check the interface status (unless you want to). After all the high level interface status (the interface is 'up', 'running', has an IP address, a DHCP lease etc.) doesn't reflect the low level status (PHY knows there's a link) so it's not like you can ever guarantee any connectivity. Which you can't anyway as the remote host or an intermediate hop after the local eth switch may be down anyway. Even then, init_all_network_interfaces() is meant to be a convenience function, and nothing stops someone bringing up the interfaces themselves (using the existing init_all_network_interfaces() as a template if need be). Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss