From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13807 invoked by alias); 25 Sep 2009 03:12:50 -0000 Received: (qmail 13797 invoked by uid 22791); 25 Sep 2009 03:12:49 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=BAYES_00,RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Sep 2009 03:12:44 +0000 Received: from list by lo.gmane.org with local (Exim 4.50) id 1Mr1Ee-0001gp-AT for ecos-discuss@sources.redhat.com; Fri, 25 Sep 2009 05:12:40 +0200 Received: from 68.168.167.52 ([68.168.167.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Sep 2009 05:12:40 +0200 Received: from grant.b.edwards by 68.168.167.52 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Sep 2009 05:12:40 +0200 To: ecos-discuss@sources.redhat.com From: Grant Edwards Date: Fri, 25 Sep 2009 03:12:00 -0000 Message-ID: References: <6afa98b0909240334i7536f39drfce21817f2fe686c@mail.gmail.com> <4ABB9D9D.3080309@jifvik.org> <4ABC0AA4.4040208@jifvik.org> User-Agent: slrn/0.9.8.1pl1 (Linux) X-IsSubscribed: yes 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: [ECOS] Re: connect ethernet cable at run-time X-SW-Source: 2009-09/txt/msg00238.txt.bz2 On 2009-09-25, Jonathan Larmour wrote: > Grant Edwards wrote: >> If one calls init_all_network_interfaces() before the Ethernet >> link is up does the DHCP code give up and terminate? IOW, >> doesn't the DHCP client code retry if it doesn't get a >> response? That seems a bit odd. > > I don't believe it does retry at present. Our customers very rarely use DHCP, so I guess we've never tripped over that one. It doesn't really sound like acceptible behavior for an embedded product does it? > See for example in dhcp_prot.c that do_dhcp() calls > no_lease(), whicih disables and deletes the alarm. Without > that the needs_attention semaphore is not posted and the dhcp > management thread gets stuck waiting on it. That's my belief > anyway. I'm sure you're right. It never even occurred to me that an embedded DHCP client would act that way. I'm pretty sure it wouldn't be considered tolerable in any of the applications where our eCos based products are used. I'll have to file a bug. :/ -- Grant -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss