Sorry, what I mean is we have to be careful what we put into the kernel image, so that different people can build kernels that are byte for byte the same given a git ref. This reproducible build stuff is all the rage now.
I think putting stuff like paths in the kernel binary will defeat reproducible builds. ron On Sun, Dec 13, 2015 at 9:50 AM 'Davide Libenzi' via Akaros < [email protected]> wrote: > Did not parse that ☺ > > > On Sun, Dec 13, 2015 at 9:48 AM, ron minnich <[email protected]> wrote: > >> One thing is it would be nice if however we do this, we can make sure we >> have reproducible builds, which the >> ELF approach might cause trouble with. >> >> ron >> >> On Sun, Dec 13, 2015 at 9:43 AM 'Davide Libenzi' via Akaros < >> [email protected]> wrote: >> >>> There is a way, and Linux perf has an ID for every trace, ID which you >>> can bind to any event string you can push into the perf file. >>> But, in order to do that, I will need to add libpfm4 dependency to >>> kprof2perf, which is not worth it. >>> Instead I will go ahead to move the akaros to linux perf conversion, to >>> the akaros perf tool (which already has the libpfm4 dependency), and drop >>> the kprof2perf tool altogether. >>> In order to do that though, I will need to know, on the Akaros side, the >>> full path within the build directory, of the akaros kernel ELF file. >>> A couple of solutions which come to my mind: >>> >>> 1) Build system create a magic build info file into KFS >>> 2) Build info are stuck in a kernel ELF section, retrievable via system >>> call or #some-dev-file >>> >>> >>> >>> >>> >>> On Sat, Dec 12, 2015 at 4:53 PM, Davide Libenzi <[email protected]> >>> wrote: >>> >>>> On Fri, Dec 11, 2015 at 12:09 PM, Davide Libenzi <[email protected]> >>>> wrote: >>>> >>>>> > +void perfmon_interrupt(struct hw_trapframe *hw_tf, void *data) >>>>>> > +{ >>>>>> > + int i; >>>>>> > + struct perfmon_cpu_context *cctx = >>>>>> PERCPU_VARPTR(counters_env); >>>>>> > + uint64_t gctrl, status; >>>>>> > + >>>>>> > + profiler_add_hw_sample(hw_tf); >>>>>> >>>>>> So it looks like we generate a trace whenever any of the counters >>>>>> overflow, but >>>>>> we lose track of which one overflowed. I guess that's what userland >>>>>> perf >>>>>> expects? >>>>>> >>>>> >>>>> I need to add an "ID", and figure out how to pass that to userland >>>>> perf. >>>>> Will do in follow up CL. >>>>> >>>> >>>> Actually, doing it in this stream, as tail commits. >>>> I already added an "info" field containing the event coordinates. >>>> Need to figure out how to translate it for Linux perf now ... >>>> >>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Akaros" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Akaros" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
