IMHO the full caching in the upper layers might not be fitting for some devices, like you notice. Take a device with large size (ie a memory device), or a device (think PCI, or MSR) where upper layer caching does not provide the proper coherency characteristics. Would be nice that, devices which chose (because they know they fit their device specific model), would have a common way to do that.
What I am trying now in my interrupts device, is to create a text response onto a queue, stick it to chan->aux (qclose() it on channel close()), and use a new qpread() call upon offsetted reads coming from upper layers. On Sun, Dec 6, 2015 at 11:42 AM, Dan Cross <[email protected]> wrote: > Sigh. Looks like we didn't carry that forward.... > > One possibility would be to make the device maintain a mapping between > Chan's and instances of data; when the Chan is closed, the device's 'close' > method could free the data instance. During a read, one would look up the > Chan (perhaps by e.g. value of the pointer itself) in the map to get the > copy of the data that's associated with this FID; if there is no entry, > then a copy of the data is made and added to the map. Otherwise, we respect > the offset and return the appropriate window on the data. When the FID is > clunked we throw the data away. > > Of course, there are all sorts of potential problems vis-a-vis potential > resource starvation of that map gets too big or holds on to too much data. > But I suspect that's just turning the crank type engineering to resolve. > > It'd be nice to have a little library to make it convenient.... > > On Sun, Dec 6, 2015 at 2:31 PM, 'Davide Libenzi' via Akaros < > [email protected]> wrote: > >> 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. >> > > -- > 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.
