From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [Development] Network / Systemd integration
Date: Tue, 08 May 2012 22:39:50 +0200 [thread overview]
Message-ID: <1336509590.15371.192.camel@rice-oxley.tremer.info> (raw)
In-Reply-To: <4FA961B5.4060305@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]
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(a).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(a)lan0.service, ...
network(a).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(a)lists.ipfire.org
> http://lists.ipfire.org/mailman/listinfo/development
next prev parent reply other threads:[~2012-05-08 20:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-08 18:11 Stefan Schantl
2012-05-08 20:39 ` Michael Tremer [this message]
2012-05-10 14:48 ` Stefan Schantl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1336509590.15371.192.camel@rice-oxley.tremer.info \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox