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.
