[16:06] <sadmac2> Keybuk: is it done yet? is it done yet? 8D
[16:07] <ion_> :-)
[16:09] <Keybuk> lol
[16:09] <Keybuk> I was trying to decide whether I need to write test cases for the D-Bus binding tool
[16:09] <Keybuk> I have test cases for its output already
[16:09] <Keybuk> (ie. C code that tests code generated by the binding tool)
[16:10] <Keybuk> and was trying to decide whether I needed to test the binding tool to make sure it output code
[16:10] <Keybuk> but then I realised it'd be basically one big strcmp in the test case
[16:10] <Keybuk> so am starting to think that's over testing
[16:11] <ion_> Heh
[16:12] <sadmac2> yeah
[16:18] <sadmac2> Keybuk: I'm looking again at dipping into kernelspace to create the IO mechanism logd needs
[16:43] <Keybuk> I'm still hopeful that we can find some way to integrate logd with syslog and klog
[16:43] <Keybuk> either the standard implementations, or a replacement
[16:44] <Keybuk> though if we want to be able to mail output in failure, it may need to be internal to init itself
[16:45] <ion_> How about init just gathering the messages to a growing buffer, and dumping them to syslog whenever it becomes available?
[16:52] <Keybuk> that's probably what we'd have to do
[16:52] <Keybuk> that would be zero lines of code, which isn't bad ;)
[16:52] <Keybuk> since it's the direct inverse of how upstart runs shell scripts
[16:53] <Keybuk> it has an arbitrary buffer in which it dumps the entire shell script for drip-feeding to the shell fd
[16:53] <Keybuk> it'd just be the inverse, drip feed by read() not write()
[16:53] <Keybuk> which I happily implemented at the time
[16:53] <ion_> :-)
=== mbiebl_ is now known as mbiebl