Fuggetaboudit ... vprintfmt() is perfect ☺
On Mon, Dec 7, 2015 at 11:17 AM, Davide Libenzi <[email protected]> wrote: > 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.
