Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: UNIX Facilities for Interpreters - (nf)
Message-ID: <7168@mimsy.UUCP>
Date: Tue, 23-Jun-87 01:20:44 EDT
Article-I.D.: mimsy.7168
Posted: Tue Jun 23 01:20:44 1987
Date-Received: Wed, 24-Jun-87 03:10:18 EDT
References: <540@iscuva.UUCP> <8300006@iaoobelix.UUCP> <680@nu3b2.UUCP> <684@nu3b2.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 113

>In article <544@iscuva.ISCS.COM> boba@iscuva.ISCS.COM (Bob Alexander) writes:
>>Robert, I think your reading a lot more complexity into this file
>>mapping business than there needs to be. ...  Although the call
>>looks something like a read, no data is actually transferred.
>>This file data is just mapped in to the caller's address space.

In article <684@nu3b2.UUCP> rwhite@nu3b2.UUCP (Robert C. White Jr.) writes:
>OK, so whare does the file come from??  Is it in a special disk
>partition, and loaded at system boot time?

The file comes from the file system, of course.  With mmap, you
write

	fd = open(filename, mode);
	if (fd < 0) ...		/* error */
	/* mmap(addr, len, protection, share, fd, offset); */
	mmap(buf, filesize, PROT_READ, MAP_SHARED, fd, (off_t) 0);

>If no data is transferd, why does the call require an established
>buffer pointer to an established buffer?

So that data can be transferred later:

	char c = buf[n];

causes a page fault, identifying some particular byte that must now
be read from the file.

>>The mechanism is completely independent from the file system buffer
>>cache.

>As I gathered, but for an open file the above questions aplied imply
>that the system buffer catche & read could, and does, preform all the
>functions of vread.

Not quite.  In particular, the semantics are different.  The character
buf[n] is automatically associated with the current contents of
location offset+n in file fd, where `current' means `at the time the
byte is read from memory'.  To do the same thing on a traditional
Unix system, you must do this:

	if (lseek(fd, offset+n, 0) == -1) ...	/* error */
	if (read(fd, &c, 1) != 1)		/* error */

In addition to being clumsier to code, this is much less efficient
on a paging machine than simply using the paging hardware.  In this
particular example, the kernel would mark invalid the appropriate
pages associated with the user buffer whenever any other programs
wrote over that file.  Until then, those pages would remain valid
and readable, and afterward, once referenced, those pages would be
reread automatically and again be valid and readable.

>>The file's data is accessed just like a memory access.

>Once again, what's the buffer for?

It names the addresses the user program wants to have reflect the
contents of the file.  For this reason, `addr' must be page aligned
(a restriction I consider bogus, although for efficiency. . .).

>>Decisions about what parts of the file are read into real memory when
>>are made by exactly the same mechanisms as regular virtual memory.
>>Parts (i.e. pages) of the file are simply paged in as needed.  No
>>special tuning is required.

>Can the file still be used normally?

*These*, now, are the sticky questions.  Yes.

>How does the system know to page it?

Programs that do not use mmap() must not see that it is being paged.
Programs that do use mmap() must see it being paged.  It is up to
the kernel to maintain the proper illusions.

>does this pass through the system cache buffers?

Typically, there are no system cache buffers.  Everything is done
with mirrors (page mapping, with copies made as necessary).

>Lastly, what if someone modifies the file in a normal manner while
>it is in the page buffer?

As to this I am uncertain.  If you have specified MAP_SHARED, it
seems that you should see such changes.  If you have said MAP_PRIVATE,
should the system copy the old pages and update the PTEs to point
to the new copies before overwriting the old data?  Or do you get
the changes anyway, MAP_PRIVATE meaning only that if you write to
the pages, they are copied?

One question you missed is `what happens if I map a 100K file and then
someone truncates it to zero bytes'?  (Answer:  Who knows?  Some say
SIGBUS.)

>>No consideration need be given to whether the file is open or not
>>(in fact, the mapped file can be accessed after it is closed --
>>just like a "read" buffer can be accessed after the file is closed).

This sounds somewhat suspicious, but certainly convenient.

>>The nice thing about mapped files is that, for the most part, they are
>>just a repackaging of existing facilities.

>As I said... What's the point?

There are several:
  - The new kernel runs faster (for some selected set of benchmarks);
  - The new kernel code is simpler;
  - Mapped file semantics are more convenient for some programs;
  - Mapped files provide shared memory.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris