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.
> 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).
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.
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.
