On Mon, Dec 7, 2015 at 5:37 AM, barret rhoden <[email protected]> wrote:
> Seems reasonable, though as you said, it'd be nice for a common way to
> do that. What exactly does qpread() do? Does it discard things it
> jumps over? It wasn't clear to me that you need anything other than
existing queue ops.
>
No, qpread() does not discard. Like pread(), simply reads at offset.
Is the model something like "if the queue is empty, generate a full
> message and attach it to the queue. read from the queue until it is
> done, then return 0 from the read" What does an lseek do? maybe for
> SEEK_SET: flush the queue, generate a new message, seek to offset.
>
For #arch/interrupts device, is create response at open(), free at close(),
and use at read() (using qpread()).
The lseek() is a layer above that, which simply changes the pointer with
which read(2) are coming to the device.
There are actually problems with just about every device like this.
> For instance, mpstat's write needed commands like "reset". At one
> point, you'd get things like this:
>
> / $ echo reset > /prof/mpstat
> Bad command, use "reset|on|off"
>
> It happened intermittently (on a given boot, there was a chance you'd
> get this behavior all the time. otherwise never (this was somehow due
> to glibc and busybox)).
>
> The issue was that echo was splitting the write too. e.g.
> write(fd ,"r"), write(fd, "eset") (it was more complicated than that,
> due to the layers of glibc and I/O buffering and whatnot). (Check out
> c074a35e7f17 ("BB: manually writes echo's buffer") and 9a3ce3138e00
> ("Busybox echo buffers lines to stdout") for more info).
>
> So even the simplest command could fail. Likewise what seems like a
> simple read (hey, it's just 10 bytes!) could be split.
>
> Another related problem is if you have two commands, one of which is a
> prefix of the other. Say "reset" and "reset_all". You try to write
> "reset_all", but it gets split by some intermediate program to "reset"
> and "_all". Whoops!
>
> This isn't quite the same issue as with read(), where new results are
> created with each partial read and the results change between the
> reads, but it's in the same ballpark.
>
I think it is OK to require that writes are atomic. The user should send in
the whole buffer.
This is, /methink, like Linux procfs stuff (and its seq_file) work as well.
We cannot OTOH, require the user to slurp in everything in one read.
Will test on Linux, but I think those are the procfs semantics.
--
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.
