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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 09, 2014 at 02:56:24PM -0400, Dan Mace wrote:
> Hello!
> 
> We've been working on golang bindings to the systemd journal interface (sd-journal.h), as well as a higher level go API which builds on the bindings.  The immediate goal is to replace  the use of forked calls to journalctl in a project.  To that end, we've been wrapping only the subset of sd-journal.h necessary to build the go API necessary to support existing journalctl usages.

Hi,

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.

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.

Print seems less than ideal. You really want to include the source
file/line location of the caller. I don't know how this might work in
go, but you can have a look at the C implementation in
src/systemd/sd-journal.h and the Python implementation in
src/python-systemd/journal.py in systemd sources. Alternatively, if
it cannot be implemented, it'd be better to use SD_JOURNAL_SUPPRESS_LOCATION
to avoid those fields altogether.

Also, Print() should really take a format string like
sd_journal_print() not just the message, to be convenient and
consistent.

In some places in the go code '%s' is used with numerical 'err'.
Does this work at all?

Also, simply printing the numerical error codes into the error
message doesn't seem very developer friendly. Why not use strerror?

Also, is it not possible to return the real errno code in
the exception (or whatever errors.New is)? Without the numerical
value the caller cannot really do any sensible error handling.
And EIO requires completely different handling than e.g. ENOENT.

> The work is currently taking place in my fork of the go-systemd project:
> 
>   https://github.com/ironcladlou/go-systemd/compare/cgo-journal
> 
> (The only test code there is a work-in-progress scratchpad I've been using for iterative development- actual tests are forthcoming once we're satisfied there won't be any more API churn.)
> 
> We've observed a segfault during this simple test, but only once:
> 
>   http://fpaste.org/107299/14019224/
It's hard to say with the scant backtrace. But I don't recall
ever seeing any crashes related to sd_journal_wait.

Zbyszek