I created a ros/memops.h include file where I added
{get,put}_le_u{16,32,64}() APIs, so that I can use them in kernel and
userspace.
If we want to convert the macros into that, we will have to decide.On Sat, Nov 28, 2015 at 7:45 AM, Davide Libenzi <[email protected]> wrote: > There is no reason, for the perf case, to have a single user, as long as > they go through a kernel API to manipulate (and allocate) the MSRs. > You can have one user wanting to watch TLB flushes, and another branch > misses, for example. > Where it gets overlapped, is when one wants to trace by time sampling, and > one by counter overflow sampling. > I am planning to add an ID to the trace sample, but I need to re-look at > Linux perf format and how to pass it to it. > > > On Sat, Nov 28, 2015 at 7:27 AM, ron minnich <[email protected]> wrote: > >> On Plan 9 the model is that ctl files are text, since it's a distributed >> system; data files are arbitrary. I was just looking at the draw device and >> it's an interesting example of a data file with structure such that you can >> import the draw device from (e.g.) an ARM to (e.g.) an x86, which is what >> we do when we use the 'cpu' command. >> >> http://man.cat-v.org/plan_9/3/draw >> >> I have no idea if this helps but there it is. >> >> I kind of agree with Davide that a clone file is not needed. You can >> differentiate sessions in the chan you get from open. >> >> Also, depending on usage, one thing that we might pick up from Plan 9 is >> the 'single open' attribute, which if set on a file is honored by the >> kernel: the file can only be open by one user at a time. This works because >> servers honor it too. It's handy. >> >> Hope this helps ... >> >> ron >> >> On Sat, Nov 28, 2015 at 7:22 AM 'Davide Libenzi' via Akaros < >> [email protected]> wrote: >> >>> Also, any reason why those could not be static inline (and turned into >>> something like get_u16, put_u16, ...)? >>> Are they something coming from imported code, which we do not want to >>> change name? >>> >>> >>> On Sat, Nov 28, 2015 at 7:19 AM, Davide Libenzi <[email protected]> >>> wrote: >>> >>>> On Fri, Nov 27, 2015 at 9:16 AM, barret rhoden <[email protected]> >>>> wrote: >>>> >>>>> > Question. Should I force the payloads to be strings, or should I use >>>>> > binary? Example: >>>>> > >>>>> > struct req1 { >>>>> > uint32_t size; >>>>> > uint32_t req; >>>>> > uint32_t cnt; >>>>> > uint64_t something[NMAX]; >>>>> > }; >>>>> >>>>> You could also use a binary, arch-independent format. That struct has >>>>> endianness assumptions. But you can still use a binary format of your >>>>> choosing. >>>>> >>>>> For another example, in Plan 9 (and Akaros), when we read() a >>>>> directory, we get a byte stream of format 'M'. In Akaros, we convert >>>>> those to structs for our own processing (e.g. convM2kdirent(), which >>>>> you can see in a few places in kern/src/ns/sysfile.c). There are >>>>> similar ones, e.g. convM2D(). >>>>> >>>>> There's a bunch of helpers to convert from bytes to fields, e.g. >>>>> GBIT8() and write fields as bytes (PBIT8()). >>>>> >>>>> What I'd do is come up with what you want the structs to look like, >>>>> then write little conv() helpers. For example: >>>>> >>>>> conv_req1_to_X(struct req1 *req1, uint8_t *buf, size_t len) >>>>> { >>>>> PBIT32(buf, req1->size); >>>>> buf += BIT32SZ; >>>>> PBIT32(buf, req1->req); >>>>> buf += BIT32SZ; >>>>> PBIT32(buf, req1->cnt); >>>>> buf += BIT32SZ; >>>>> for (int i = 0; i < NMAX; i++) { >>>>> PBIT64(buf, req1->something); >>>>> buf += BIT64SZ; >>>>> } >>>>> } >>>>> >>>>> (written hastily, checkout convD2M for a better example). >>>>> >>>> >>>> These interfaces though, are not exposed to userspace, so I will have >>>> to move them into a dedicated ros/ file, I guess? >>>> >>>> >>> -- >>> 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.
