[systemd-devel] [PATCH 3/3] run: introduce timer support option

[Lennart Poettering]

On Thu, 23.10.14 15:25, WaLyong Cho (walyong.cho at gmail.com) wrote:

> On 10/23/2014 12:56 AM, Lennart Poettering wrote:
> >On Tue, 07.10.14 14:20, WaLyong Cho (walyong.cho at samsung.com) wrote:
> >
> >>If systemd-run is called with timer option, then systemd-run call
> >>NewTransientUnit with service unit. And also call StartTransientUnit
> >>with timer unit which has same name with the service. So actually, two
> >>method call is coming and two transient unit is generated. One is
> >>service and the other is timer.
> >>
> >>Supported timer options are --after=, --after-boot=, --after-startup=,
> >>--after-active=, --after-inactive=, --calendar=, --accuracy= and
> >>--wake-system. Each option corresponding with OnActiveSec=,
> >>OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=,
> >>AccuracySec= and AccuracySec= of timer respectively.
> >
> >Hmm, I'd really like to stay close to the underlying props here in
> >naming, and call the options "--on-boot=", "--on-inactive=" and so on
> >(the -sec suffix we can probably drop).
> >
> I'd really tought and worried about naming of the options. At the first
> time, I'd made similar named option with timer unit. But I tought the
> command line options should be more meaningful or easy to understand. So I
> changed like this. But if you say so, I don't want to against to your
> opinion. I will change those.

I think the easiest to understand is if we keep the cmdline options
and the options in the files similar in name.

> >This stuff really should not store the string, but the parsed value.
> >
> Yeah, a couple of parse_sec doesn't make sense.
> How about calendar_spec_from_string? calendar_spec_from_string also be
> called twice on run and dbus-timer. I'm not sure the parsed calendar spec is
> able to be sent on current StartTransientUnit() interface. But even if
> possible, just string is obiously easy to send and receive. How do you
> think?

Yeah, the calendar spec stuff is different, it's so complex that it
isn't fun to encapsulate in a parsed way in dbus. That's why the bus
property for OnCalendar actually contains a formatted string.

On the client side we should parse everything as early as possible
into the format we want to pass it over dbus in. This means for
OnCalendar to leave it as string, but for the others to parse it into
an usec_t.

Thanks!

Lennart

-- 
Lennart Poettering, Red Hat