[systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API

[Dan Mace]

----- Original Message -----
> From: "Brandon Philips" <brandon at ifup.co>
> To: "Zbigniew Jędrzejewski-Szmek" <zbyszek at in.waw.pl>
> Cc: "Dan Mace" <dmace at redhat.com>, "systemd Mailing List" <systemd-devel at lists.freedesktop.org>,
> appinfra-list at redhat.com
> Sent: Thursday, June 19, 2014 3:28:06 PM
> Subject: Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
> 
> On Sat, Jun 14, 2014 at 8:13 AM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > I think that designing the api in steps like this will make it harder
> > to get a consistent design. The journal api is rather small, so I don't
> > think it is hard to cover most of it in the initial design. In my
> > experience, getting sd_journal_print, sd_journal_send, sd_journal_sendv
> > wrappers consistent requires some care.
> 
> I agree, I would rather do this all at once.

Agree.

> > About the proposed go api:
> >
> > I think the reader and writer apis should be totally separate.
> > Different files/modules/whatever. They don't share implementation,
> > and usually are not used together.

Agree.

> Yes, I agree. Actually, is there a reason to bind to the C
> sd_journal_print if we already have a pure Go version of
> sd_journal_send?
> https://github.com/coreos/go-systemd/blob/master/journal/send.go
> 
> > In some places in the go code '%s' is used with numerical 'err'.
> > Does this work at all?
> 
> Yes it works, Go's print is typesafe but it will look strange:
> %!s(int=42). We should probably turn them into syscall.Errno() type.

Oversights on my part.  This is rough POC code.  I agree they should be translated.

> > It's hard to say with the scant backtrace. But I don't recall
> > ever seeing any crashes related to sd_journal_wait.
> 
> Dan, how do you want me to help out with this? I am happy to dig in if
> you want to share a branch or something. Or you can send a PR and we
> can start from there.
> 
> Brandon
> 
> [1] http://play.golang.org/p/zTOuMj-sg7
> [2] http://play.golang.org/p/NDnJF8Zocf
> 

This is on my backburner at the moment while I work on some other things.  Hitting the segfault while testing our primary use case and being unable to reproduce the error made me nervous enough that I don't feel comfortable promoting any of the current work yet.  I was hoping something obvious would jump out, or somebody else running the test from my branch would be able to observe the segfault and have a better ability to debug.  My branch[1] is still in the same state as before.  I don't think a PR makes sense quite yet until there's increased confidence in the stability.  Without knowing the cause, I can't predict the impact to the design that might come with the solution.

-- Dan

[1] https://github.com/ironcladlou/go-systemd/compare/cgo-journal