And here is the root of the argument -- where it is all going towards. > If we decide to handle this in netstart alone, shouldn't all interfaces > behave like vport(4) and not mess with their state unless explicitly > requested to do so?
the implication here, is let's go change all the drivers and network stack to not "auto-up", because netstart will handle it. Absolutely no, because noone has tested this in all configurations and all the new implications that are being ignored in this proposal because it is only trying to fix another small nit. I am not thrilled about where this is going. Yes, there are obscure corner cases configuring network device "graphs". And the answer is to keep re-arranging netstart? I'm not sure about that. And now the conversation heads towards "drivers should not come up automatically", and "drivers should be pre-created". I think this is just deck chair re-arrangement. Lots of people do manual configuration, where they DON'T USE sh netstart, and their fingers have memories ... but this proposal of "netstart does it", and "drivers don't do it", is basically telling them to register at a re-education camp. Another way of looking at this, is that the situation isn't that bad, because it makes the simple device/network usages .... very simple to use. OpenBSD isn't a brand-name enterprise switch or router. I'm familiar with the usage pattern on such devices. That does not mean I (or others) automatically require the "kind of implied atomicity" of only bringing up interfaces "late". Even on major routers/switches, this is such a small little thing -- the management of those devices requires that you to have brought the devices down before you make changes, otherwise there is no manual "up" step, because you as an admin left it "up" while you were making changes. So the transaction model you want to enforce here with netstart is only concerned with the "up" side, there is no implied "down", there cannot be an implied "down" side... unless you mean people should reboot to test? A bit of hyperbole, but why solve the "do not auto up" if during re-configuriaton people are very often already going to be up??? So, I do not understand the end-game of this proposal. I mean, beyond fresh boot. But now to tie this into "devices should not come up on their own", why does that even MATTER during the few moments of bring-up. Chasing ghosts? And yes I know the routing daemons are processing excessive messages, but isn't it their job to normally process potentially many more messages than this meager amount, and isn't it good that such code is actually being tested to behave correctly? In summary, there are undeal setups. Does it mean everything has to change those to satisfy those few odd cases? I don't see justification.
