[systemd-devel] [Cocci] systemd m4 library complex systemd example, and coccinelle conversion

[Luis R. Rodriguez]

On Wed, Jun 25, 2014 at 02:24:44PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jun 25, 2014 at 10:20:11AM +0200, Luis R. Rodriguez wrote:
> > On Mon, Jun 23, 2014 at 03:19:30PM +0200, Lennart Poettering wrote:
> > > On Thu, 12.06.14 18:04, Luis R. Rodriguez (mcgrof at do-not-panic.com) wrote:
> > > 
> > > > Hey folks,
> > > > 
> > > > so I've been working on getting systemd support on xen for a bit now
> > > > and thanks to the last suggestion about the launcher here on
> > > > systemd-devel I think we're on the final stretch now. I'll be
> > > > submitting a v6 PATCH series shortly which I think should be the last
> > > > if not close to the last set we need. It turns out though that I ran
> > > > into quite a few issues though, what I consider corner cases with
> > > > systemd, and in order to help I've tried to put together a simple
> > > > package example source code which exemplifies the complexities I found
> > > > but more importantly provide the resolutions to those issues. At the
> > > > same time xen also is a good example of a complex piece of software
> > > > with multiple OS requirements and on the Linux font you may or may not
> > > > want systemd, it also happened to use autoconf, but not automake, and
> > > > in one iteration of patches I even worked on systemd support with the
> > > > dynamic link loader (dlopen() and dlsym()). Adding proper support for
> > > > systemd into xen turned out to be a bit of a mini project. In order to
> > > > try to help other though I've generalized as much as I can the
> > > > autotools functionality I wrote given I was unable to find a library
> > > > to easily add systemd. I'd like your review of this piece of code and
> > > > wanted to see if perhaps at least the LGPL m4 libraries might be
> > > > welcomed.
> > > > 
> > > >   * src/m4/systemd.m4
> > > > 
> > > >     - AX_ENABLE_SYSTEMD(): enables systemd by default and requires an
> > > >       explicit --disable-systemd option flag to configure if you want to
> > > >       disable systemd support.
> > > > 
> > > >     - AX_ALLOW_SYSTEMD(): systemd will be disabled by default and requires
> > > >       you to run configure with --enable-systemd to look for and enable systemd
> > > > 
> > > >     - AX_AVAILABLE_SYSTEMD(): systemd will be disabled by default but if your
> > > >       build system is detected to have systemd build libraries it will be
> > > >       enabled. You can always force disable with --disable-systemd
> > > > 
> > > >     - If you want to use the dynamic link loader you should use
> > > >       AX_AVAILABLE_SYSTEMD() but must then ensure to use -rdynamic -ldl
> > > >       when linking, if using automake autotools will deal with this for you,
> > > >       otherwise you must ensure this is in place on your Makefile.
> > > 
> > > Hmm, so, I don't think systemd should really be treated differently from
> > > other pkg-config-enabled modules. What precisely does this add that
> > > pkg-config doesn't support? And wouldn't it be possible to improve
> > > pkg-config upstream instead?
> > 
> > pkg-config is a helper to let you figure out what you have installed,
> > flags required, etc. It doesn't do the autoconf voodoo dance which
> > is simply a nightmare. Relying on pkg-config also assumes systemd
> > has done the right job on all aspects of variables but as the m4
> > library annotates there a few areas where this could be enhanced
> > so it tries to centralize this on an m4 library for userspace.
> Some libraries have their own detection macros, and they are more pain than
> it is worth. The reason is that the macro has to be available even if the
> library is not installed, which means that the macro has to be copied into
> the other project, or wrapped with a macro which detects that the macro is
> not available, before using it. Either option is unattractive and simply
> using pkg-config for everything turns out to be much cleaner. Of course this
> means that one has to provide special macros for pkg-config, but that's easier
> than adding custom support for every dependency.

Good points -- that or autoconf gets replaced with something much more
easier and modern that makes this seemless, but that certainly is a
tangent.

> > > I don't think we want to support the dlsym() stuff in systemd
> > > directly. I mean, if people want to do things like that, that's fine,
> > > but I really doubt we should encourage that from upstream.
> > 
> > Makes sense, its an option and the vodoo is done, if they inist the
> > purpose of the funkd-systemd code is to say -- its done, and go at it,
> > here's an example.
> > 
> > > Also note that pretty much any Linux distributions (modulo
> > > Gentoo/Slackware) uses systemd already or announced plans to do so, I am
> > > not sure it's worth really investing so much time in making systemd
> > > optional beyond the usual what pkg-config supports.
> > 
> > It wasn't clear to me while learning about systemd so I was just agnostic
> > to that. Its all there as options, people can choose.
> > 
> > > > Lastly -- I was curious if anyone has looked into writing Coccinelle
> > > > SmPL grammar rules to convert legacy init systems with systemd
> > > > support. I suspect most unix daemons are rather simple and SmPL rules
> > > > might be able to transform quite a bit of them. I don't expect
> > > > Coccinelle might be able to catch the crazy daemons with corner cases
> > > > as with xen, but you never know, coccinelle is always surprising me
> > > > with its capabilities.
> > > 
> > > Note that distribuitions like Fedora have already pretty much converted
> > > all their daemons (with exceptions), so I figure this in many ways is
> > > too late... 
> > 
> > Conversion to me means sd_notify(), what does it mean to you? Either way
> > stats can help with this specially to inspire folks who may wish to
> > convert daemons from legacy init script port to proper sd_notify(), or
> > from fork to sd_notify(). Granted we can't expect full conversion on
> > the simple service type to sd_notify() easily but what I was aiming
> > for here in the argument for SmPL was to see what was left from
> > legacy fork to sd_notify().
> Some services are best converted to socket activation, others to Type=fork,
> others to Type=notify... Converting sysv scripts is mostly about removing
> cruft, something that would be very hard for a script to do.

True, I was thinking about C deamons that were already forking.

  Luis