[ECOS] Re: connect ethernet cable at run-time
Sun Sep 27 22:06:00 GMT 2009
Grant Edwards wrote:
> On 2009-09-25, Jonathan Larmour <email@example.com> wrote:
>>But yes that does confirm that an unplugged cable at startup
>>means no IP address unless the user calls
>>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).
--["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
More information about the Ecos-discuss