git: 318ceda5fb - main - articles/vm-design: Fix typo
"Danilo G. Baio" <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
The branch main has been updated by dbaio: URL: https://cgit.FreeBSD.org/doc/commit/?id=318ceda5fb29eee8ab7dd7622d7db280c1a123d3 commit 318ceda5fb29eee8ab7dd7622d7db280c1a123d3 Author: Danilo G. Baio <[email protected]> AuthorDate: 2022-04-23 12:37:25 +0000 Commit: Danilo G. Baio <[email protected]> CommitDate: 2022-04-23 12:37:25 +0000 articles/vm-design: Fix typo Submitted by: dymil Pull Request: https://github.com/freebsd/freebsd-doc/pull/65 --- documentation/content/en/articles/vm-design/_index.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/content/en/articles/vm-design/_index.adoc b/documentation/content/en/articles/vm-design/_index.adoc index cac81535c5..7499c1e362 100644 --- a/documentation/content/en/articles/vm-design/_index.adoc +++ b/documentation/content/en/articles/vm-design/_index.adoc @@ -106,7 +106,7 @@ Data may be modified on a page-by-page basis whereas the file mapping encompasse The complexity further increases when a process forks. When a process forks, the result is two processes-each with their own private address spaces, including any modifications made by the original process prior to the call to `fork()`. It would be silly for the VM system to make a complete copy of the data at the time of the `fork()` because it is quite possible that at least one of the two processes will only need to read from that page from then on, allowing the original page to continue to be used. -What was a private page is made copy-on-write again, since each process (parent and child) expects their own personal post-fork modifications to remain private to themselves and not effect the other. +What was a private page is made copy-on-write again, since each process (parent and child) expects their own personal post-fork modifications to remain private to themselves and not affect the other. FreeBSD manages all of this with a layered VM Object model. The original binary program file winds up being the lowest VM Object layer.