Hi Alvin,

>>> systemd specifies a special passive target unit 'network-pre.target'
>>> which may be pulled in by services that want to run before any network
>>> interface is brought up or configured. Correspondingly, network
>>> management services such as iwd and ead should specify
>>> After=network-pre.target to ensure a proper ordering with respect to
>>> this special target.
>>> 
>>> For more information, see systemd.special(7) and [1].
>>> 
>>> [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freedesktop.org%2Fwiki%2FSoftware%2Fsystemd%2FNetworkTarget%2F&data=04%7C01%7CALSI%40bang-olufsen.dk%7Ca9129a1177e04d6a153008d8bedee80e%7C210d08b883f7470abc96381193ca14a1%7C0%7C0%7C637469211873327131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K3cEG17BYuVdWg9JlwqCIpmOkGYa1esk8gdFbGewuME%3D&reserved=0
>> 
>> so what does this really do in practice. Both daemons are fully hotplug aware and it makes no difference when they are started.
> 
> I can give two examples.
> 
> The first is practical and we encountered it in our embedded system. The 
> second is hypothetical, but perhaps a little more convincing.
> 
> 1. We have a oneshot service which must run to perform some platform 
> specific configuration of our wireless network interface before it is 
> ready to be used. One such thing is does is set the MAC address 
> according to some data in an EEPROM. While restructuring the service 
> file for this oneshot service I removed the line:
> 
> 	Before=iwd.service systemd-networkd.service
> 
> and replaced it with:
> 
> 	Before=network-pre.target
> 
> ... as is suggested in systemd's documentation. This seemed good to me 
> because it is more generic.
> 
> I then noticed that during boot, iwd would run before this service and 
> connect to an AP. The AP was then kicking us off during the MAC address 
> change. This is how I noticed that iwd was not respecting the 
> network-pre.target order.
> 
> FYI we are using a driver (brcmfmac) which doesn't allow 
> creating/destroying the primary interface.
> 
> 2. Since iwd (and ead? never used it) can also do IP network 
> configuration, it's possible that it runs and does this stuff before 
> certain firewall rules are applied. This is the rationale given in the 
> systemd documentation.

fair points. Please put them into the commit message so that when we ever git blame this change, we know why it made sense.

Just to note, I always hate that if you have to delay a service from starting up as early as possible and get the hardware ready to be used. Nobody worried about these things until we made it so blazing fast that WiFi will be ready and connected before you need it. They way how it should have been from the start.

Regards

Marcel