Re: [PATCH 1/2] ios: Introduce ios_flush and ios_dev_<...>_flush.

[Jose E. Marchesi]

    > Thanks for the patch.
    >
    >      +/* If the current IOD is a write stream, write out the data in the 
buffer
    >      +   till OFFSET.  If the current IOD is a stream IOD, free (if 
allowed by the
    >      +   embedded buffering strategy) bytes up to OFFSET.  This function 
has no
    >      +   impact when called on other IO devices.  */
    >      +
    >      +int ios_flush (ios io, ios_off offset)
    >      +  __attribute__ ((visibility ("hidden")));
    >
    > In poke regular (non-stream) IO spaces are currently not buffered,
    > meaning the data is immediately written to the underlying device once a
    > write operation is issued.
    >
    > Therefore, I would expect that a write to an output stream IOS would
    > actually write everything up to that offset, including the data written.
    
    I am not sure if it is good to immediately write stuff that gets into
    an output stream. If we do that, folks would need to prepare
    everything outside of the buffer and then only use the output stream
    to output. I was imagining scenarios such as reading data from the
    input stream and just copying it to output stream as bulk data. Then,
    one can just map the interesting parts of it and modify, while the
    input stream remains unchanged for reference.
    
    Of course I am not sure how useful this is. But if you think it is not
    useful not to write out immediately, we do not need a buffer for out 
    streams at all.

    > Note I'm not questioning the pertinence of being able to apply ios_flush
    > to an output stream, that may be useful by itself.
    >
    > But I wonder about the language-level construct, i.e.:
    >
    > Should we have a "forget" operation that calls ios_flush only on read
    > streams and that is a NOP on any other kind of IO spaces including write
    > streams?
    >
    > Or should we have a "flush" operation that can be called on both input
    > and output streams?
    
    As I said, I think the output buffer provides a tabula rasa for people
    who want to output a modified version of the input but also to keep
    the original input unmodified for reference. If you do not think that
    is useful, I can remove the usage of buffer from output streams of
    course, that would be quite easy. I took your question as a
    non-rhetorical one. If you actually prefer the output stream to
    directly write out (which might be more intuitive to first-time
    users),  let me know and I'll change that.


I see what you mean.  That's a very good observation!

The challenge here is to make streams look like regular IO spaces, which
are addressable.

However, I am very sure we should keep the well-understood nature of
streams of being either read-only or write-only:

- You can map stuff in stdin, in any offset.  If the offset is before
  the range of existing data (i.e. before the last offset "forgotten" or
  "flushed") you get an EOF exception (for Early Of File :)).

- You can map stuff in stdout, but only on an offset equal or bigger
  than the iosize of the IOS.  In other words, you can only append to
  the output stream.  If you specify an offset past of the current
  iosize of the output stream, the IO subsystem should write zeroes
  until either the specified offset is reached.

My fear is that if we do anything else, even if it is more powerful,
people could get easily lost.  Including myself :)

My idea is that a memory-backed IOS can be used as a cheap and
convenient intermediate area for massaging/working on the data.

The typical filter would become:

   read bytes from input to mem -> filter/massage  in mem -> write from
   mem to output