On 2015-12-07 at 10:50 "'Davide Libenzi' via Akaros"
<[email protected]> wrote:
> Yes, but it's much easier not to have to worry about sizes (and
> potential reallocs - had by any chance the size of the response
> changed, from the initial calculation, to the rendering point), and
> just do:
>
> struct foo* f = foo_create();
>
> foo_write(f, ...);
> foo_write(f, ...);
> foo_write(f, ...);
> foo_write(f, ...);
Yes, that is easy.
Is that write method something that works with snprintf? That's the
usual way that we build these. Here's a common pattern:
p = s = kzmalloc(READSTR, 0);
p = seprintf(p, e, "lintr: %ud %ud\n", ctlr->lintr, ctlr->lsleep);
p = seprintf(p, e, "rintr: %ud %ud\n", ctlr->rintr, ctlr->rsleep);
p = seprintf(p, e, "tintr: %ud %ud\n", ctlr->tintr, ctlr->txdw);
n = readstr(offset, a, n, s);
Or do we have to kmalloc buffers and append them? Or something else?
> Head and tail appending (which /methink are the only cases which we
> need to support), can just update the current (head or tail) buffer
> in place.
Do we need head appending? Don't we always know that stuff (e.g. the
header for a text table) in advance?
I also think that this misses my concern about the size from the
previous email. We might be asked for the size of a file before the
buffer is created (i.e. before open()). If we can't generate it at
runtime, say as a function of num_cores, then we can't give an accurate
stat() response.
That's not the hugest deal in the world, but if we can deal with it,
then it'd be nice.
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.
