[ECOS] Re: connect ethernet cable at run-time

[Jonathan Larmour]

Grant Edwards wrote:
> On 2009-09-25, Jonathan Larmour <jifl@jifvik.org> 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