Re: [TUHS] Systematic approach to command-line interfaces

[Dan Cross <crossd@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3553 bytes --]

On Wed, Sep 29, 2021 at 2:08 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > From: Larry McVoy
>
>     > If you read(2) a page and mmap()ed it and then did a write(2) to the
>     > page, the mapped page is the same physical memory as the write()ed
>     > page. Zero coherency issues.
>
> Now I'm confused; read() and write() semantically include a copy operation
> (so there are then two copies of that data chunk, and possible consistency
> issues between them), and the copied item is not necessarily page-sized (so
> you can't ensure consistency between the original+copy by mapping it in).
> So
> when one does a read(file, &buffer, 1), one gets a _copy of just that byte_
> in the process' address space (and similar for write()).
>
> Yes, there's no coherency issue between the contents of an mmap()'d page,
> and
> the system's idea of what's in that page of the file, but that's a
> _different_ coherency issue.
>
> Or am I confused?
>

I think that mention of `read` here is a bit of a red-herring; presumably
Larry only mentioned it so that the reader would assume that the read
blocks are in the buffer cache when discussing the write vs mmap coherency
issue with respect to unmerged page and buffer caches (e.g., `*p = 1;`
modifies some page in the VM cache, but not the relevant block in the
buffer cache, so a subsequent `read` on the mmap'd file descriptor won't
necessarily reflect the store).

I don't think that is strictly necessary, though; presumably the same
problem exists even if the file data isn't in block cache yet.

PS:
>     > From: "Greg A. Woods"
>
>     > I now struggle with liking the the Unix concept of "everything is a
>     > file" -- especially with respect to actual data files.  Multics also
> got
>     > it right to use single-level storage -- that's the right abstraction
>
> Oh, one other thing that SLS breaks, for data files, is the whole Unix
> 'pipe'
> abstraction, which is at the heart of the whole Unix tools paradigm. So no
> more 'cmd | wc' et al. And since SLS doesn't have the 'make a copy'
> semantics of pipe output, it would be hard to trivially work around it.
>

I don't know about that. One could still model a pipe as an IO device;
Multics supported tapes, printers and terminals, after all. It even had
pipes!
https://web.mit.edu/multics-history/source/Multics/doc/info_segments/pipes.gi.info

Yes, one could build up a similar framework, but each command would have to
> specify an input file and an output file (no more 'standard in' and 'out'),


Why? To continue with the Multics example, it supported `sysin` and
`sysprint` from PL/1, referring to the terminal by default.


> and then the command interpreter would have to i) take command A's output
> file
> and feed it to command B, and ii) delete A's output file when the whole
> works
> was done. Yes, the user could do it manually, but compare:
>
>   cmd aaa | wc
>
> and
>
>   cmd aaa bbb
>   wc bbb
>   rm bbb
>
> If bbb is huge, one might run out of room, but with today's 'light my cigar
> with disk blocks' life, not a problem - but it would involve more disk
> traffic, as bbb would have to be written out in its entirety, not just
> have a
> mall piece kept in the disk cache as with a pipe.
>

It feels like all you need is a stream abstraction and programs written to
use it, which doesn't seem incompatible with SLS. Perhaps the argument is
that in a SLS system one wouldn't be motivated to write programs that way,
whereas in a program with a Unix-style IO mechanism it's more natural?

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 4861 bytes --]