[systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
Lennart Poettering
lennart at poettering.net
Tue Nov 26 09:10:37 PST 2013
On Thu, 21.11.13 02:27, Tom Gundersen (teg at jklm.no) wrote:
> > Maybe then back to labelled sections:
> >
> > [Address:foobar]
> > Label=waldo
> > Address=1.1.1.1
> >
> > or so, so that the suffix "foobar" is purely an id that is by default
> > disconnected from any setting? And then maybe optionally inherit it into
> > Label= if Label= is not explicitly set?
>
> I think the section name should not have any other function/meaning. I
> first tried to make 'section name'='Label', but I'm worried it might
> be confusing: If section names are required, it means we now require
> labeling, or force the admin to set "Label=" to disable it, which
> seems a bit weird.
It hink that would actually be OK. Doing something useful without
explicit configuration sounds like a good approach. Inheriting the
Label= from the section name if no explicit Label= is specified sounds
quite OK to me...
> Also, I find it asymmetric the way section names
> for Addresses have this extra meaning, but for Routes or other types
> of sections where there is no natural equivalent to Label=, they have
> no meaning apart from a name.
Well, we wouldn't really bind the section name only and exclusively to
the label. It's just that when fields are not explicitly set they might
inherit the section name, in some field-specific way. For Label= it
would be quiet obvious, but for other things this might work too. For
example, for the ipv6 tunnel stuff we could inherit the section name
into the tunnel iface name or so, whatever comes up...
> I'm really not convinced one way or the other, but I think my
> preferred solution is: go with unnamed sections now, and if ever it
> becomes necessary, introduce named ones additionally.
Sounds OK.
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list