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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
