Does not look that neither the VFS entry, nor the plan9 entry, of sys_read(), have that model, AFAICS. They just issue ->read() call on the device function.
On Sun, Dec 6, 2015 at 11:23 AM, Dan Cross <[email protected]> wrote: > On Sun, Dec 6, 2015 at 1:28 PM, 'Davide Libenzi' via Akaros < > [email protected]> wrote: > >> Yes, I saw the helpers. That is not the issue. >> The issue is that an always regenerated response will potentially always >> change, hence the continuation offset the userspace will issue at the next >> read, will not read where it left. >> > > The plan 9 I/O model doesn't work this way. In particular, it preserves > message boundaries on reads (with the caveat that writes of zero bytes are > discarded so that one won't be confused with EOF). If we've carried this > forward into Akaros, then the device should make sure that it has enough > room to build a response in the output buffer when it's read function is > invoked, but otherwise not worry about it: the upper layers of the queue > and channel abstractions will make sure that the user-space process always > gets the right amount of data so that message boundaries are not crossed in > a single read. > > That is, if I issue two writes to a file descriptor, each emitting 25 > bytes of output, and something that's consuming that data issues two read > calls reading up to 20 bytes, then the first will get 20 bytes and the > second will get a short read of 5 bytes. If I again read two bytes, then > I'll get the next message in the same way: I'll read 20 bytes and then > again 25 bytes. > > The critical point is that there's a queue abstraction mediating between > userspace and the kernel's read() method, so that userspace reads are not > one-to-one with invocations of the kernel's read method for any particular > file descriptor associated with a device. > > - Dan C. > > IMO the response should be cached, so that both the size of it, and the >> content, fit a rolling offset read model. >> Cached, but when? >> Once at device open()? Does it provide the right refresh semantics? >> Once every time offset==0? >> >> >> >> On Sun, Dec 6, 2015 at 10:22 AM, Dan Cross <[email protected]> wrote: >> >>> There are some helper functions for this for various types of data; >>> readnum, readstring, etc. I can't remember if there is a 'readbytes' but it >>> would be useful to add.... >>> >>> On Sun, Dec 6, 2015 at 1:05 PM, 'Davide Libenzi' via Akaros < >>> [email protected]> wrote: >>> >>>> When userspace open a device for read, it typically reads the response >>>> in chunks, with rolling offsets for the reads. >>>> In the few devices I had my eyes on (kprof/mpstat for one), and in the >>>> new interrupts one, we build a new response at every read, and use the >>>> offset to return the proper section of it. >>>> This is clearly not right, as offsets mean different things at >>>> different times, as response contents are not the same. >>>> These kind of devices needs to have some notion of caching the content, >>>> otherwise userspace will read garbage on the seams. >>>> >>>> -- >>>> 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. >>> >> >> -- >> 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. > -- 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.
