On Fri, Nov 27, 2015 at 9:16 AM, barret rhoden <[email protected]> wrote:
> On 2015-11-27 at 8:24 'Davide Libenzi' via Akaros wrote:
> > I don't think I need a clone thing, once agreed I can use the
> > read+write transaction model on the perfctl device.
>
> Is there just one perfctl file that you'd be operating on? I thought
> the benefit of the clone was that you could create several separate
> files in #perf that could be opened by independent perf sessions.
>
> Though I agree that clone isn't necessarily the only way to do that.
> You could have a limited number of files under #perf, and only allow
> them to be opened by one user at a time. Or any number of things.
>
I assume that, like in every other OS, if two processes (or even the same
process twice) open a given file, there will be a separate struct chan* for
each, right?
If so, I don't need clone.
>
> > 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:
>
OK, sticking with binary.
>
> 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).
>
> Then the conv_X_to_req1() is the reverse, using GBIT32s, like convM2D.
> (And we might want a name for X).
>
> So you get to keep things binary, with relatively low overhead, and
> it's still arch / endian independent.
>
> I don't think that having a full string interface (e.g. req={2}, etc)
> is necessary, since I don't see shell scripts or interactive use being
> a big deal for this device.
>
--
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.
