[systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name

Kay Sievers kay at vrfy.org
Wed Nov 20 17:47:48 PST 2013


On Thu, Nov 21, 2013 at 2:39 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Thu, Nov 21, 2013 at 02:27:28AM +0100, Tom Gundersen wrote:
>> On Wed, Nov 20, 2013 at 10:37 PM, Lennart Poettering
>> <lennart at poettering.net> wrote:
>> > On Wed, 20.11.13 14:38, Tom Gundersen (teg at jklm.no) wrote:
>> >
>> >> Pass on the line on which a section was decleared to the parsers, so they
>> >> can distinguish between multiple sections (if they chose to). Currently
>> >> no parsers take advantage of this, but a follow-up patch will do that
>> >> to distinguish
>> >>
>> >> [Address]
>> >> Address=192.168.0.1/24
>> >> Label=one
>> >>
>> >> [Address]
>> >> Address=192.168.0.2/24
>> >> Label=two
>> >>
>> >> from
>> >>
>> >> [Address]
>> >> Address=192.168.0.1/24
>> >> Label=one
>> >> Address=192.168.0.2/24
>> >> Label=two
>> >
>> > I do like this solution better, but I can see Thomas' point. And the
>> > issue Thomas points out manifests itself in handling of .d/
>> > directories... If we want to support .d/ directories for these
>> > configuration files (do we?) then how can we extend the settings of a
>> > specific existing [Address] section?
>>
>> My take was that we do not want to support .d/ directories,

> udev supports overrides, tmpfiles support them too, so do systemd
> units, and sysctl settings. I'm pretty sure we can assume that
> overrides for network files will happen sooner or later. Also, it's
> not just /etc/...  overriddes, but also /run/... overrides, for
> until-reboot settings.


Nah, this is only about fragment drop-ins, they are only supported by
unit files.

The network files surely support individual files in a directory, but
not fragments to overwrite parts of a file.

As mentioned earlier, network files are like udev rules, the file name
is meaningless, so .d/ fragment drop-ins make not much sense here.

Kay


More information about the systemd-devel mailing list