On 2015-12-14 at 11:06 "'Davide Libenzi' via Akaros" <[email protected]> wrote: > > We've been a little lax with adding code and dealing with licenses > > in the past. I'd like it to be clear from the commit message where > > code came from. I take it then that you added libpfm4-4.6.0 or > > something from http://perfmon2.sourceforge.net/, possibly from > > git://git.code.sf.net/p/perfmon2/libpfm4. > > > > Should I amend the commit, or add a README into the library (or both)?
thanks for amending it. i was taking care of some other things and didn't get to this email in time. =) > > Still, I'm fine with the lock (per cpu or global). I (and > > perhaps whoever reads the code in the future) just want to know if > > there's something to be worried about. > > > > Well, multiple call from different tasks can come in, and the > operations against the per CPU counters are definitely not atomic. They should be atomic on Akaros, since the kernel messages (which smp_do uses) aren't interruptible. Let's leave the locks in for now - they aren't hurting. > > which is before perfmon_install_session_alloc(). > > > > That's the sort of thing that could catch someone in the future, > > even if it is unlikely. I wasn't asking for the code to change; I > > was just saying that a comment would have made it more clear both > > for me and for future developers. We ought to be explicit about > > any of the invariants about locking or concurrent access. > > > > Should I add? I'd appreciate a one-liner in there that says something like "pa must be read-only once we publish it" > I will revise that with Makefrag-user-app idea, until we decide for > the future layout. Sounds great. Thanks for the fixes btw. =) Barret -- 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.
