Hey Stefan,
I have some amendments on this proposal because I am mainly uncomfortable with putting systemd on charge to bring up the network zones. The network code should be able to determine which zones are brought up and when.
Therefore, creating symlinks on our own in the systemd filesystem is not a good idea.
We should be able to control zones independently and systemd should control the status of it. We can achieve this by using the network@.service which could be started by the "network start" command.
The boot process could look like this:
network.service - Manageable by the user. (pre-exec) network init (exec ) network start `--> Starts all zones: network@lan0.service, ...
network@.service - Controls a single zone (exec ) network zone lan0 up
network.target Doesn't really do anything but needed to indicate that the network is up. However, I am not sure yet what could be a criteria, because I don't want to wait until all zones are properly set up (internet connections take some time and should not block the boot process).
Maybe somebody else has got a good idea for this.
----
I figure this setup will help us a lot. systemd is controlling the zones and sets them up and down. So a lot of this will be done in parallel and doesn't block anything else.
The network code could hold down some zones or all of them when it is told to do so by the kernel command line for example. I can think of some more cases which are all easily to implement in this scenario.
Michael
On Tue, 2012-05-08 at 20:11 +0200, Stefan Schantl wrote:
Hello,
On the Developer Summit we have spoken about network and systemd - how our implemention works and how we can improve it.
I've written a roadmap which contains all changes and new features.
http://wiki.ipfire.org/devel/network/systemd
Please read through and perform any feedback or any new idea's you have.
Thanks,
Stefan _______________________________________________ Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development