Re: [systemd-devel] [RFC][PATCH] conf-parser: allow instanced sections
On 11/19/2013 09:20 PM, Tom Gundersen wrote: On Tue, Nov 19, 2013 at 7:07 PM, Colin Guthriegm...@colin.guthr.ie wrote: What I have in mind (though it is not dictated by this patch) is something different (first proposed by Lennart in an earlier thread): [Network] Address=192.168.0.1/24 Address=192.168.0.2/24 Gateway=192.168.1.1 [Address:oneaddress] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 [Address:anotheraddress] Address=192.168.0.4/24 Label=four In this case we'll configure four addresses. The two first ones could also have been expressed as: [Address:foo] Address=192.168.0.1/24 [Address:bar] Address=192.168.0.2/24, but we allow putting them directly in the [Network] section rather than in a named [Address] section as a shorthand. Notice that if we simply did [Address] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 [Address] Address=192.168.0.4/24 Label=four, that wouldn't work as it is (at least currently) equivalent to [Address] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 Address=192.168.0.4/24 Label=four, which is why we need to give the secitons unique names. Arent's we sacrificing significant part of simplicity in units going down this path as opposed to have users use per unit interface instances units and templating/instances ? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: allow instanced sections
On Wed, Nov 20, 2013 at 12:02 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/19/2013 09:20 PM, Tom Gundersen wrote: On Tue, Nov 19, 2013 at 7:07 PM, Colin Guthriegm...@colin.guthr.ie wrote: What I have in mind (though it is not dictated by this patch) is something different (first proposed by Lennart in an earlier thread): [Network] Address=192.168.0.1/24 Address=192.168.0.2/24 Gateway=192.168.1.1 [Address:oneaddress] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 [Address:anotheraddress] Address=192.168.0.4/24 Label=four In this case we'll configure four addresses. The two first ones could also have been expressed as: [Address:foo] Address=192.168.0.1/24 [Address:bar] Address=192.168.0.2/24, but we allow putting them directly in the [Network] section rather than in a named [Address] section as a shorthand. Notice that if we simply did [Address] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 [Address] Address=192.168.0.4/24 Label=four, that wouldn't work as it is (at least currently) equivalent to [Address] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 Address=192.168.0.4/24 Label=four, which is why we need to give the secitons unique names. Arent's we sacrificing significant part of simplicity in units going down this path as opposed to have users use per unit interface instances units and templating/instances ? I don't quite follow how that would work? You may be right that this is not the simplest syntax though, I'm trying to come up with something better. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: allow instanced sections
On Wed, Nov 20, 2013 at 12:02 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/19/2013 09:20 PM, Tom Gundersen wrote: On Tue, Nov 19, 2013 at 7:07 PM, Colin Guthriegm...@colin.guthr.ie wrote: What I have in mind (though it is not dictated by this patch) is something different (first proposed by Lennart in an earlier thread): [Network] Address=192.168.0.1/24 Address=192.168.0.2/24 Gateway=192.168.1.1 [Address:oneaddress] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 [Address:anotheraddress] Address=192.168.0.4/24 Label=four In this case we'll configure four addresses. The two first ones could also have been expressed as: [Address:foo] Address=192.168.0.1/24 [Address:bar] Address=192.168.0.2/24, but we allow putting them directly in the [Network] section rather than in a named [Address] section as a shorthand. Notice that if we simply did [Address] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 [Address] Address=192.168.0.4/24 Label=four, that wouldn't work as it is (at least currently) equivalent to [Address] Address=192.168.0.3/24 Label=three Peer=192.168.1.1 Address=192.168.0.4/24 Label=four, which is why we need to give the secitons unique names. Arent's we sacrificing significant part of simplicity in units going down this path as opposed to have users use per unit interface instances units and templating/instances ? I think it's ok. But we should probably answer why we don't simply allow the repetition of plain sections, like we allow the repetition of identical keys in them. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: allow instanced sections
'Twas brillig, and Tom Gundersen at 19/11/13 16:57 did gyre and gimble:
This will treat [Section:bar], [Section:foo], and [Section:baz],
as [Section], but pass on the full section name to the options parser
so it can treat them separately.
What is the semantics here? (I should probably know as you've likely
posted it already!)
e.g. I've seen the following semantics before for ini-style parsing:
[database]
database.adapter = pdo_mysql
database.params.host = db.dev
database.params.username = ninja
database.params.password = dressedinblack
[mydb : database]
database.params.dbname = mydatabase
This basically means the mydb section inherits from the database
section and only changes what it needs.
It seems you're using using this slightly differently in that you'll have a:
[General]
Address=xyz
and then a
[Address:xyz]
section? i.e. the instances section actually inherits from an earlier value?
If so then I doubt the semantics here can be generalised to this other
example in which case my comment is rather moot!
So take this comment with a pinch of salt :D
@@ -253,17 +255,27 @@ static int parse_line(const char* unit,
if (!n)
return -ENOMEM;
-if (sections !nulstr_contains(sections, n)) {
+e = strchr(n, ':');
+if (e)
+m = strndup(n, e - n);
+else
+m = strdup(n);
+
+if (sections !nulstr_contains(sections, m)) {
Do you want to do some whitespace trimming here perhaps? e.g. if n is
Foo :bar or Foo : bar or Foo: bar etc.
being silently tolerant of this is probably most sensible I guess.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: allow instanced sections
On Tue, Nov 19, 2013 at 7:07 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
'Twas brillig, and Tom Gundersen at 19/11/13 16:57 did gyre and gimble:
This will treat [Section:bar], [Section:foo], and [Section:baz],
as [Section], but pass on the full section name to the options parser
so it can treat them separately.
What is the semantics here? (I should probably know as you've likely
posted it already!)
e.g. I've seen the following semantics before for ini-style parsing:
[database]
database.adapter = pdo_mysql
database.params.host = db.dev
database.params.username = ninja
database.params.password = dressedinblack
[mydb : database]
database.params.dbname = mydatabase
This basically means the mydb section inherits from the database
section and only changes what it needs.
It seems you're using using this slightly differently in that you'll have a:
[General]
Address=xyz
and then a
[Address:xyz]
section? i.e. the instances section actually inherits from an earlier value?
What I have in mind (though it is not dictated by this patch) is
something different (first proposed by Lennart in an earlier thread):
[Network]
Address=192.168.0.1/24
Address=192.168.0.2/24
Gateway=192.168.1.1
[Address:oneaddress]
Address=192.168.0.3/24
Label=three
Peer=192.168.1.1
[Address:anotheraddress]
Address=192.168.0.4/24
Label=four
In this case we'll configure four addresses. The two first ones could
also have been expressed as:
[Address:foo]
Address=192.168.0.1/24
[Address:bar]
Address=192.168.0.2/24,
but we allow putting them directly in the [Network] section rather
than in a named [Address] section as a shorthand.
Notice that if we simply did
[Address]
Address=192.168.0.3/24
Label=three
Peer=192.168.1.1
[Address]
Address=192.168.0.4/24
Label=four,
that wouldn't work as it is (at least currently) equivalent to
[Address]
Address=192.168.0.3/24
Label=three
Peer=192.168.1.1
Address=192.168.0.4/24
Label=four,
which is why we need to give the secitons unique names.
If so then I doubt the semantics here can be generalised to this other
example in which case my comment is rather moot!
So take this comment with a pinch of salt :D
@@ -253,17 +255,27 @@ static int parse_line(const char* unit,
if (!n)
return -ENOMEM;
-if (sections !nulstr_contains(sections, n)) {
+e = strchr(n, ':');
+if (e)
+m = strndup(n, e - n);
+else
+m = strdup(n);
+
+if (sections !nulstr_contains(sections, m)) {
Do you want to do some whitespace trimming here perhaps? e.g. if n is
Foo :bar or Foo : bar or Foo: bar etc.
being silently tolerant of this is probably most sensible I guess.
Yes, that's probably a good idea. Thanks.
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
