Currently I don't have a "printf" interface. It's snprintf+write.
It is useful to have, but have the issue that you need to know the size of
the final printf, in order to reserve the proper space.
Nothing huge, but it needs to be addressed.
As far as stat size goes, not many of our devices (and linux procfs ones as
well), export a size.
IMHO it is not a big deal, as those are used like:
int fd = open("/some/foo", O_RDONLY);
while (read(fd, ...)) {
...
}
An fstat would fit, as at that point when we have a valid channel, we also
have the size of the response.
On Mon, Dec 7, 2015 at 11:06 AM, Barret Rhoden <[email protected]> wrote:
> 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.
>
--
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.
