HECnet

hecnet@lists.dfupdate.se

15559 discussions

by Paul_Koning＠Dell.com

On Dec 19, 2012, at 1:08 PM, Johnny Billquist wrote: On 2012-12-19 17:38, Paul_Koning at Dell.com wrote: On Dec 19, 2012, at 7:08 AM, Johnny Billquist wrote: On 2012-12-19 03:27, Clem Cole wrote: The page size on the VAX is 512 bytes and it lacked COW (copy-on-write) HW (long, long story as to why, which I will not try to repeat). In the end, this would be a huge problem with all VAX OSses and HW - take look any of the sources. [...] Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table. However, it's extremely easy to implement it, and the cost is acceptable, I guess. You just keep the page read-only, and get a trap when someone wants to write. At that time you change the protection, and mark it as modified. There are even a couple of bits in the page entry that are reserved for software use, and you can just decide that one of them is your modified bit. This is what we do in NetBSD/vax. I can't imagine any other way of doing it. A copy on write page has to start out read-only, then when the write occurs the write has to be rejected so the copy can be done first. The "trap, copy, and write-enable" approach is the common one; for example, MIPS works exactly this way. Well, I was talking about implementing the MODIFY bit here, but yes, copy-on-write is an extension to this. However, I pretty much am sure that you cannot do it any easier to cheaper with copy-on-write. The MODIFY bit, though, is something most MMUs have in hardware - not so for the VAX. :-( That becomes important when you want to know if a page is dirty or not... Good point. MIPS is an example of an MMU that doesn't have a modified bit. It has a bit named "dirty" in the page entry, but that's a misleading name -- it is in reality the write-enable bit. paul

12 years, 5 months

2.11BSD

by bqt＠softjar.se

On 2012-12-19 17:38, Paul_Koning at Dell.com wrote: On Dec 19, 2012, at 7:08 AM, Johnny Billquist wrote: On 2012-12-19 03:27, Clem Cole wrote: The page size on the VAX is 512 bytes and it lacked COW (copy-on-write) HW (long, long story as to why, which I will not try to repeat). In the end, this would be a huge problem with all VAX OSses and HW - take look any of the sources. [...] Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table. However, it's extremely easy to implement it, and the cost is acceptable, I guess. You just keep the page read-only, and get a trap when someone wants to write. At that time you change the protection, and mark it as modified. There are even a couple of bits in the page entry that are reserved for software use, and you can just decide that one of them is your modified bit. This is what we do in NetBSD/vax. I can't imagine any other way of doing it. A copy on write page has to start out read-only, then when the write occurs the write has to be rejected so the copy can be done first. The "trap, copy, and write-enable" approach is the common one; for example, MIPS works exactly this way. Well, I was talking about implementing the MODIFY bit here, but yes, copy-on-write is an extension to this. However, I pretty much am sure that you cannot do it any easier to cheaper with copy-on-write. The MODIFY bit, though, is something most MMUs have in hardware - not so for the VAX. :-( That becomes important when you want to know if a page is dirty or not... Johnny

12 years, 5 months

2.11BSD

by Paul_Koning＠Dell.com

On Dec 19, 2012, at 7:08 AM, Johnny Billquist wrote: On 2012-12-19 03:27, Clem Cole wrote: The page size on the VAX is 512 bytes and it lacked COW (copy-on-write) HW (long, long story as to why, which I will not try to repeat). In the end, this would be a huge problem with all VAX OSses and HW - take look any of the sources. [...] Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table. However, it's extremely easy to implement it, and the cost is acceptable, I guess. You just keep the page read-only, and get a trap when someone wants to write. At that time you change the protection, and mark it as modified. There are even a couple of bits in the page entry that are reserved for software use, and you can just decide that one of them is your modified bit. This is what we do in NetBSD/vax. I can't imagine any other way of doing it. A copy on write page has to start out read-only, then when the write occurs the write has to be rejected so the copy can be done first. The "trap, copy, and write-enable" approach is the common one; for example, MIPS works exactly this way. paul

12 years, 5 months

Expanding MONITOR CLUSTER to use full terminal screen?

by system＠TMESIS.COM

"Brian Schenkenberger, VAXman-" <system at TMESIS.COM> writes: "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> writes: sampsa at mac.com writes: > >>Is there some switch I can use to make MONITOR CLUSTER use a larger >>screen than 80x24? > >I looked in the HELP commands but found nothing >related. > >??? > >I routinely have 132 column SHOW CLUSTER display. I have a number of >ADD commands in my SHOW_CLUSTER$INIT.INI file which cause SHOW CLUSTER >to use the full 132 columns of my display. What is the width of your >terminal? (ie. $ WRITE SYS$OUTPUT F$getdvi("TT","DEVBUFSIZ") returns >what?) Sorry, too early in the morn... MONITOR, not SHOW, CLUSTER. OK. I just checked the sources for MONITOR and this is fixed. Here's a comment from CLUFAO: ; The cluster screen in divided up into quadrants by a horizontal and verticle ; line. The quadrants are all equal in size (10 rows x 39 columns). The upper ; left quadrant displays the top 6 nodes CPU_BUSY statistic. The Upper right ; quadrant displays the top 6 MEMORY_UTILIZATION statistic. The lower left ; quadrant displays the top 6 disks total I/O rate statistic. And the lower ; left quadrant is up for grabs at this point. Following this comment, there's a table which contains cursor positioning values. All would maintain output that is strictly 80 column. If you're looking for a 132 column variant, it looks like you'll have to write this yourself. It should be pretty simple to do. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 5 months

Expanding MONITOR CLUSTER to use full terminal screen?

by system＠TMESIS.COM

"Brian Schenkenberger, VAXman-" <system at TMESIS.COM> writes: sampsa at mac.com writes: Is there some switch I can use to make MONITOR CLUSTER use a larger screen than 80x24? > >I looked in the HELP commands but found nothing related. ??? I routinely have 132 column SHOW CLUSTER display. I have a number of ADD commands in my SHOW_CLUSTER$INIT.INI file which cause SHOW CLUSTER to use the full 132 columns of my display. What is the width of your terminal? (ie. $ WRITE SYS$OUTPUT F$getdvi("TT","DEVBUFSIZ") returns what?) Sorry, too early in the morn... MONITOR, not SHOW, CLUSTER. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 5 months

Expanding MONITOR CLUSTER to use full terminal screen?

by system＠TMESIS.COM

sampsa at mac.com writes: Is there some switch I can use to make MONITOR CLUSTER use a larger screen than 80x24? I looked in the HELP commands but found nothing related. ??? I routinely have 132 column SHOW CLUSTER display. I have a number of ADD commands in my SHOW_CLUSTER$INIT.INI file which cause SHOW CLUSTER to use the full 132 columns of my display. What is the width of your terminal? (ie. $ WRITE SYS$OUTPUT F$getdvi("TT","DEVBUFSIZ") returns what?) -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 5 months

Expanding MONITOR CLUSTER to use full terminal screen?

by sampsa＠mac.com

Is there some switch I can use to make MONITOR CLUSTER use a larger screen than 80x24? I looked in the HELP commands but found nothing related. sampsa

12 years, 5 months

2.11BSD

by clemc＠ccc.com

Correct. Not having it is expensive, and adds difficulties to the SW. This is why wnj created/implemented vfork(2) for 4.1. While most codes could just s/fork/vfork/ careful reading needed to occur and some rewriting needed to happen. The HW guys finally relented. On Wed, Dec 19, 2012 at 7:08 AM, Johnny Billquist <bqt at softjar.se> wrote: Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table.

12 years, 5 months

2.11BSD

by bqt＠softjar.se

On 2012-12-19 03:27, Clem Cole wrote: The page size on the VAX is 512 bytes and it lacked COW (copy-on-write) HW (long, long story as to why, which I will not try to repeat). In the end, this would be a huge problem with all VAX OSses and HW - take look any of the sources. [...] Well, what it lacks (and I'm sure you know this) is really a modified bit in the page table. However, it's extremely easy to implement it, and the cost is acceptable, I guess. You just keep the page read-only, and get a trap when someone wants to write. At that time you change the protection, and mark it as modified. There are even a couple of bits in the page entry that are reserved for software use, and you can just decide that one of them is your modified bit. This is what we do in NetBSD/vax. I don't know of any architecture that has any kind of copy-on-write semantics in the MMU. I think that is way to complex to actually be possible in the MMU itself. OSes normally do copy-on-write by having the page read-only, and when a write happens, the page gets cloned, and then you have your own private copy, to which you can write. But that implies allocating a new page, copy the contents of the old page over, and change the current page table. If you know of an MMU that can do that, I'm interested in hearing about it. Johnny

12 years, 5 months

Post-mail server migration test post/area status

by gregg.drwho8＠gmail.com

On Wed, Dec 19, 2012 at 1:10 AM, Cory Smelosky <b4 at gewt.net> wrote: Feel free to disregard, I was just playing with SPF records and I migrated away from gmail and wanted to make sure emails still get places properly. Had to make sure, always a chance I broke something. ;) Also: I will very soon have time to get back to making area 9 work. Hello! Disregard what? It works. Good for you. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

12 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet