Hey all, Next steps for logging were discussed in the CDM last night. Seems like we're going to move forward on validating the use of lttng as a full-bore logging replacement. Check it out (on youtube, as usual) if you're interested! -Greg On Wed, Apr 25, 2018 at 8:50 AM, Adam C. Emerson <aemerson@xxxxxxxxxx> wrote: > On 25/04/2018, kefu chai wrote: > [snip] >> yeah, in addition to encode()/deocde()/print()/operator<<, we could have >> another log() function for every struct/class, which need to be logged. >> this function will prepare a pair of <index, list of address/length pair>, so >> the underlying logger can dump the interesting bits to disk with the recipe >> index to print these bits. > > That sounds reasonable. That can handle the case of logging an object > that contains several strings, say. And if we have just return a > std::array of spans we can just allocate it on the stack. > > -- > Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US > IRC: Aemerson@OFTC, Actinic@Freenode > 0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9 > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
