Thanks for your extensive and very well written emails. Looking at this thread it's clear that there indeed "there are two different world views of the conceptual purpose of net_if_up() and net_if_down()."
To add to the discussion I would like to remind here one design issue related to Ethernet drivers which, I belive, is not yet clarified. As principle Ethernet drivers are initialized before the network stack is. Currently the initialization process involves bringing up the interface and establishing a functioning data link. If at that time Ethernet driver receives an RX frame it will try to forward it to the network stack even if it may not be initialized yet. That's a race condition. One way to solve it would be to have an interface enable/disable function. The data link would be established only when it is explicitly requested by the network stack.
As you have mentioned a few times already we also need to handle a scenario where a user unplugs the network cable and plugs it in some time later possibly on a different LAN. So also for me the option 2) seems like a more natural way forward.
> 2) We keep the enable/disable semantic. This implies:
> - We split net_if_up/down into net_if_enable/disable() and
> net_if_up/down() such that net_if_enable calls l2->enable() while
> net_if_up/down deals with NET_IF_UP and raising net_event_if_up/down
> - The hardwired net_if_up() calls at network stack boot are switched
> to call net_if_enable()
> - The BT L2 enable callback is used to turn advertising on/off
> - Every network device needs to call net_if_up() once it has a link
> established (and net_if_down when it drops). (BT already does this)
I'm only not sure how an interface power up / power down functionality fits in here. In any case the final say belongs to the network stack maintainers.