public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Grant Edwards <grant.b.edwards@gmail.com>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS]  Re: connect Ethernet cable at run-time
Date: Sat, 26 Sep 2009 15:11:00 -0000	[thread overview]
Message-ID: <h9latr$g5f$1@ger.gmane.org> (raw)
In-Reply-To: <26548.8079087392$1253952764@news.gmane.org>

On 2009-09-26, Laurie Gellatly <laurie.gellatly@netic.com> wrote:

> For our product there is a reason. If there is no Ethernet
> connection other operations can still be done.

They can't be done while the DHCP client retries?

> As the web server is monitored by the watchdog it's important
> that it not get stuck waiting on DHCP.

I guess I don't understand your requirements.  If there's no
EThernet link, what else does the web server have to do except
wait for it?  It can't it kick the watchdog timer while the
DHCP client is attempting to acquire an address?

> So we don't need the device to be plugged into the network
> either and it will continue to work with what it can. When the
> network does connect, other capabilities start.

All of which is fine, but what I don't understand is why it
precludes the DHCP client from retrying.  When the DHCP client
does acquire an address and brings up the interface, then those
"other capabilities" can start.  None of my products have the
requirement that "capabilities" can only start during a certain
time window after the board starts.  They could start whenever
the Ethernet link does comes up?

> If the user wants to change between DHCP and static addresses
> then that too is possible without having to restart our
> device.

That's a nice feature, but again I don't understand why it
precludes the DHCP client from retrying.

-- 
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

  parent reply	other threads:[~2009-09-26 15:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-24 10:34 [ECOS] connect ethernet " Lars Dahlin
2009-09-24 11:45 ` Edgar Grimberg
2009-09-24 14:42 ` [ECOS] " Grant Edwards
2009-09-24 16:26   ` Jonathan Larmour
2009-09-24 16:32     ` Grant Edwards
2009-09-25  0:11       ` Jonathan Larmour
2009-09-25  1:23         ` Laurie Gellatly
2009-09-25  3:20           ` Grant Edwards
2009-09-25  3:36             ` Laurie Gellatly
2009-09-25 13:16           ` Jonathan Larmour
2009-09-25 14:54             ` Grant Edwards
2009-09-26  8:12               ` [ECOS] Re: connect Ethernet " Laurie Gellatly
     [not found]               ` <26548.8079087392$1253952764@news.gmane.org>
2009-09-26 15:11                 ` Grant Edwards [this message]
2009-09-27 22:06               ` [ECOS] Re: connect ethernet " Jonathan Larmour
2009-09-25  3:12         ` Grant Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='h9latr$g5f$1@ger.gmane.org' \
    --to=grant.b.edwards@gmail.com \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).