PDP-11 emulation and Unix v7
Joey Morris
and the v7 disk images (really cool stuff) and I was wondering
if there was a clean way to shutdown unix in those days.
init doesn't take arguments, there's no halt/shutdown
what did people do back then?
Has anybody else been using this setup? The only way I've found
to transfer files in and out the emulator is the following:
sim> set rl1 RL02
sim> att rl1 rawdisk
then after booting do
tar cf /dev/rl1 whatever
I couldn't get the tm tape devices to play nice (blocksize problems)
fun
--
Joe Morris, SysAdmin and Not Insane
253 days, 5 hours, 53 minutes, 30 seconds (GMT) until Y2K.
Sarr J. Blumson
Joey Morris <jol...@netcom.com> wrote:
>Hey, I've been playing with Bob Supnik's pdp11 simulator
>and the v7 disk images (really cool stuff) and I was wondering
>if there was a clean way to shutdown unix in those days.
>init doesn't take arguments, there's no halt/shutdown
>what did people do back then?
Just run "sync" twice and shut if off IIRC. fsck would run when you rebooted,
but it wouldn't find any problems and the disks were small...
--
--------
Sarr Blumson sa...@umich.edu
voice: +1 734 764 0253 home: +1 734 665 9591
ITD, University of Michigan http://www-personal.umich.edu/~sarr/
Eric Fischer
> Hey, I've been playing with Bob Supnik's pdp11 simulator
> and the v7 disk images (really cool stuff) and I was wondering
> if there was a clean way to shutdown unix in those days.
> init doesn't take arguments, there's no halt/shutdown
> what did people do back then?
I don't know the suggested procedure, but the v7 manpage
for init(8) notes that you can drop from multiuser to
single user mode by doing "kill -1 1" to send a signal
to init. Once you're in single user mode, it should
presumably be safe to quit the simulator after you've
done a couple of syncs.
eric
Peter Seebach
Eric Fischer <er...@fudge.uchicago.edu> wrote:
>I don't know the suggested procedure, but the v7 manpage
>for init(8) notes that you can drop from multiuser to
>single user mode by doing "kill -1 1" to send a signal
>to init. Once you're in single user mode, it should
>presumably be safe to quit the simulator after you've
>done a couple of syncs.
Weird. In BSD Unix, it's "kill 1", because "kill -1 1" re-reads /etc/ttys
and otherwise tells init to stay running but reset.
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
John A. Limpert
Joey Morris <jol...@netcom.com> wrote in message
news:jolomoFA...@netcom.com...
> Hey, I've been playing with Bob Supnik's pdp11 simulator
> and the v7 disk images (really cool stuff) and I was wondering
> if there was a clean way to shutdown unix in those days.
> init doesn't take arguments, there's no halt/shutdown
> what did people do back then?
I used to do the following.
$ telinit s
[wait for init to switch system to single-user mode]
$ sync
$ sync
[halt system]
This was on a Tektronix 8560 (LSI-11/23 UNIX).
Markus Wandel
Joey Morris <jol...@netcom.com> wrote:i
>Hey, I've been playing with Bob Supnik's pdp11 simulator
>and the v7 disk images (really cool stuff) ...
Is it just me or is this stuff a bit hard to use for non-PDP11-veterans like
this clueless spring chicken here (me, I mean.) But I've often wondered what
the real thing, of those famous 1978 manuals, would be like.
It runs great on my 450MHz overclocked Celeron Linux box, not blazingly fast
but probably fine by 1978 standards. It only takes a couple of seconds to
compile the "hello world" program for example.
Anyway to make it easier for other clueless newbies, I've figured it out
and posted a walkthrough on my web page, at
http://www.playground.net/~mwandel/unix7.html
One thing this finally let me do is try out the "learn" command. The stuff
is all there but needs a little bit of munging, for example to unpack the
"editor" lessons you need to do something like
# cd /usr/lib/learn
# mkdir play
# chmod 777 play
# mkdir editor
# cd editor
# ar x ../editor.a
(this is from memory but should be right.) Then logged in as any user you
can type "learn" and choose the subject "editor". Proceed similarly for the
other subjects.
Now could someone figure out how to make the "ps" command work? I've figured
out that the kernel must be accessable as /unix, but now it wants /dev/swap
and there is none in the disk image.
Markus
David L
> Now could someone figure out how to make the "ps" command work? I've figured
> out that the kernel must be accessable as /unix, but now it wants /dev/swap
> and there is none in the disk image.
This baffled me for a while too. The solution is to go to the /dev
directory and make a link from swap to rl0.
cd /dev
ln rl0 swap
Then, the ps caommand will work.
To logon to a working version of this over the web, visit my online
software museum at http://www.sysun.com/museum. Not only 7th edition
unix but also Altair Basic, CP/M, and RDOS are there. More to follow
when I have the time. All using the Supnik emulators or variations I've
written.
Dutch
nor...@mech.eng.usyd.edu.au
<snip>
: Has anybody else been using this setup? The only way I've found
: to transfer files in and out the emulator is the following:
<snip>
You can always mount the filesystem under Linux.
Jonathan Naylor has patched the Linux sysv filesystem module to
mount pdp11 7th Edition filesystems. I am not sure if he has
put the patch into the mainstream kernal yet. I have written a module
for accessing the 5th and 6th Edition filesystems, but it is read
only.
Ciao,
--
Stuart Norris nor...@mech.eng.usyd.edu.au
Mechanical Engineering,University of Sydney,NSW 2006 wk:+(61 2) 9351-2272
http://www.maths.unsw.edu.au/~norris hm:+(61 2) 9326-5276
greg andruk
> I was always curious why the unix manuals would always recomment
> "sync; sync; halt"
> My mentor of sorts (this was in 1984) had worked on the Nixdorf
> unix port and said it was unnecessary. "If you don't trust it
> the first time, what makes you think it's going to work the
> second time?"
> Anything I missed?
Yeah, you were looking for something to make sense. The sync(2) call
isn't necessarily, um, synchronous. It initiates a cache enema, but
can return before the data is actually written to disk (Sun and linux
work this way, other implementations may differ). Running 'sync'
twice (Hmm, I learned it as 3 times) might not do much, but at least
it buys time for the first sync to finish before the halt kicks in.
There is an fsync() that waits, but that's per descriptor instead of
for the whole system.
--
Misc. Meowing: <URL:http://members.xoom.com/meowing/> **meow**
ma...@usai.asiainfo.com
: Just run "sync" twice and shut if off IIRC. fsck would run when you rebooted,
: but it wouldn't find any problems and the disks were small...
I was always curious why the unix manuals would always recomment
"sync; sync; halt"
My mentor of sorts (this was in 1984) had worked on the Nixdorf
unix port and said it was unnecessary. "If you don't trust it
the first time, what makes you think it's going to work the
second time?"
Anything I missed?
Mark.
--
Mark Harrison "Open the floppy disk door, Hal."
AsiaInfo Computer Networks http://usai.asiainfo.com:8080/
Beijing, China / Santa Clara, CA ma...@usai.asiainfo.com
Dennis Ritchie
>
> Sarr J. Blumson <sa...@qix.rs.itd.umich.edu> wrote:
> : Just run "sync" twice and shut if off IIRC. fsck would run when you rebooted,
> : but it wouldn't find any problems and the disks were small...
>
> I was always curious why the unix manuals would always recomment
> "sync; sync; halt"
>
> My mentor of sorts (this was in 1984) had worked on the Nixdorf
> unix port and said it was unnecessary. "If you don't trust it
> the first time, what makes you think it's going to work the
> second time?"
>
> Anything I missed?
If you actually typed "sync; sync; halt" then I can see the possible
timing issue. However, if you were told to type "sync" and then do it
again, this had to do with giving you a chance to ponder whether
you remembered to do it at all the first time.
Dennis
Eric Levenez
> Sarr J. Blumson <sa...@qix.rs.itd.umich.edu> wrote:
> : Just run "sync" twice and shut if off IIRC. fsck would run when you rebooted,
> : but it wouldn't find any problems and the disks were small...
>
> I was always curious why the unix manuals would always recomment
> "sync; sync; halt"
>
> My mentor of sorts (this was in 1984) had worked on the Nixdorf
> unix port and said it was unnecessary. "If you don't trust it
> the first time, what makes you think it's going to work the
> second time?"
The first sync is first locking the superblock of the partition, then
it start writing all blocks in background.
The second sync start but stay waiting on the superblock lock until
the first one unlock it after having written all the blocks. Then
the second sync start, but leaves immediately because all the blocks
have been written.
--
--------------------------------------------------------------------
Éric Lévénez "Felix qui potuit rerum cognoscere causas"
mailto:lev...@club-internet.fr Publius Vergilius Maro,
http://perso.club-internet.fr/levenez Georgica, II-489
--------------------------------------------------------------------
"We are Microsoft. You will be assimilated. Resistance is futile."
Roman Belenov
I've heard that when the second sync command exits, the data will be
flushed. Isn't it true, at least on some systems ?
ga> Yeah, you were looking for something to make sense. The sync(2) call
ga> isn't necessarily, um, synchronous. It initiates a cache enema, but
ga> can return before the data is actually written to disk (Sun and linux
ga> work this way, other implementations may differ). Running 'sync'
ga> twice (Hmm, I learned it as 3 times) might not do much, but at least
ga> it buys time for the first sync to finish before the halt kicks in.
Best regards,
Roman mailto:ro...@nstl.nnov.ru
Luc Van der Veken
<lev...@club-internet.fr>(12 May 1999 12:43:56 GMT);
> The first sync is first locking the superblock of the partition, then
> it start writing all blocks in background.
>
> The second sync start but stay waiting on the superblock lock until
> the first one unlock it after having written all the blocks. Then
> the second sync start, but leaves immediately because all the blocks
> have been written.
What is the second sync good for, if you switch off your computer
while it's still waiting? The prompt will pop up again [after
typing the second sync] before it [the first one] has finished
anyway, it my experiences are right.
When I was small, they told me all it was about was giving the
system some time to finish the first sync.
FWIW, systems never shut down anyway (people just keep them
running to see how long it takes the OS to crash ;-)
Charlie Gibbs
(Roman Belenov) writes:
>I've heard that when the second sync command exits, the data will be
>flushed. Isn't it true, at least on some systems ?
"Sync three times on the console if you want me.
Close all the pipes if the answer is no..."
(with apologies to Tony Orlando and Dawn)
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
David Scheidt
: I've heard that when the second sync command exits, the data will be
: flushed. Isn't it true, at least on some systems ?
I was taught that sync(8) wrote all buffers that had been scheduled for a
write, and scheduled all dirty buffers for writing. By doing it twice, you
guaranteed that all dirty buffers were written to disk.
David, who supposes he should go look at the source...
--
dsch...@enteract.com
Ketchup, therefore, shows both thixotropic and pseudoplastic rheological
properties. -- John Schmitt, in AFU
Tris Orendorff
> Sarr J. Blumson <sa...@qix.rs.itd.umich.edu> wrote:
> : Just run "sync" twice and shut if off IIRC. fsck would run when you
> rebooted,
> : but it wouldn't find any problems and the disks were small...
>
> I was always curious why the unix manuals would always recomment
> "sync; sync; halt"
>
> My mentor of sorts (this was in 1984) had worked on the Nixdorf
> unix port and said it was unnecessary. "If you don't trust it
> the first time, what makes you think it's going to work the
> second time?"
Wise words, indeed. I am sure that sync originally had a timing bug and the
repeat running was to make sure it really finished. Poor planning,
shoddy programming all around followed by a poor fix by some undisciplined
code typist.
----- BEGIN GEEK CODE BLOCK -----
Version: 3.12
GCS d++ s a C+ UC++++ P+ L E- W+ N++ o- K++ w+ O+ M !V PS+ PE Y+ PGP t+ !5 X- R- tv--- b++ DI++ D+ G+ e+ h---- r+++ y+
------ END GEEK CODE BLOCK ------
Michael T Pins
>In article <12oah7...@bigbird.sw.asiainfo.com>, ma...@usai.asiainfo.com wrote:
>> Sarr J. Blumson <sa...@qix.rs.itd.umich.edu> wrote:
>> : Just run "sync" twice and shut if off IIRC. fsck would run when you
>> rebooted,
>> : but it wouldn't find any problems and the disks were small...
>>
>> I was always curious why the unix manuals would always recomment
>> "sync; sync; halt"
>>
>> My mentor of sorts (this was in 1984) had worked on the Nixdorf
>> unix port and said it was unnecessary. "If you don't trust it
>> the first time, what makes you think it's going to work the
>> second time?"
>Wise words, indeed. I am sure that sync originally had a timing bug and the
>repeat running was to make sure it really finished. Poor planning,
>shoddy programming all around followed by a poor fix by some undisciplined
>code typist.
Unwise words, indeed.
There is no guarantee that the sync will be finished before the call
returns. On many flavors of unix, the sync program only calls sync(2),
then returns control to the user. The actaul sync'ing of the discs may
or may not be finished. However, the second sync command *cannot* return
until the first sync has finished (it can't invoke sync(2) until the first
one has finished). In other words, the purpose of the second sync is to
insure the first one is actually finished.
Before you start spouting nonsense about "a timing bug" and "Poor planning,
shoddy programming", I suggest you actually find out something about what
you're talking about. Say, reading the man pages for sync and sync(2) for
starters....
--
**************************************************************************
* Michael T Pins | mtp...@visi.com *
* keeper of the nn sources | mtp...@icaen.uiowa.edu *
* ftp://ftp.visi.com/users/mtpins | #include <std.disclaimer> *
Eric Smith
> There is no guarantee that the sync will be finished before the call
> returns. On many flavors of unix, the sync program only calls sync(2),
> then returns control to the user. The actaul sync'ing of the discs may
> or may not be finished. However, the second sync command *cannot* return
> until the first sync has finished (it can't invoke sync(2) until the first
> one has finished). In other words, the purpose of the second sync is to
> insure the first one is actually finished.
If sync(2) doesn't execute synchronously, what mechanism are you claiming
that imposes the constraint "it can't invoke sync(2) until the first
one has finished"?
jmfb...@aol.com
"Charlie Gibbs" <cgi...@sky.bus.com> wrote:
>In article <19891....@nstl.nnov.ru> ro...@nstl.nnov.ru
>(Roman Belenov) writes:
>
>>flushed. Isn't it true, at least on some systems ?
>
> Close all the pipes if the answer is no..."
>
>(with apologies to Tony Orlando and Dawn)
>
until now that composing lyrics could be a very good
"how to program" device. It certainly wouldn't limit
the information to a class room.
/BAH
Subtract a hundred and four for e-mail.
jmfb...@aol.com
mtp...@visi.com (Michael T Pins) wrote:
>tr...@remove-me.inasec.ca (Tris Orendorff) writes:
>
>>In article <12oah7...@bigbird.sw.asiainfo.com>,
ma...@usai.asiainfo.com wrote:
>>> Sarr J. Blumson <sa...@qix.rs.itd.umich.edu> wrote:
>>> : Just run "sync" twice and shut if off IIRC. fsck would run when you
>>> rebooted,
>>> : but it wouldn't find any problems and the disks were small...
>>>
>>> I was always curious why the unix manuals would always recomment
>>> "sync; sync; halt"
>>>
>>> My mentor of sorts (this was in 1984) had worked on the Nixdorf
>>> unix port and said it was unnecessary. "If you don't trust it
>>> the first time, what makes you think it's going to work the
>>> second time?"
>
>>Wise words, indeed. I am sure that sync originally had a timing bug and
the
>>repeat running was to make sure it really finished. Poor planning,
>>shoddy programming all around followed by a poor fix by some
undisciplined
>>code typist.
>
>Unwise words, indeed.
>returns. On many flavors of unix, the sync program only calls sync(2),
>then returns control to the user. The actaul sync'ing of the discs may
>or may not be finished. However, the second sync command *cannot* return
>until the first sync has finished (it can't invoke sync(2) until the first
>one has finished). In other words, the purpose of the second sync is to
>insure the first one is actually finished.
>
planning,
>shoddy programming", I suggest you actually find out something about what
>you're talking about. Say, reading the man pages for sync and sync(2) for
>starters....
>
And, thus, timesharing was born. Why should a whole system wait
for a [put favorite slow device here] to finish?
Eric Fischer
> If sync(2) doesn't execute synchronously, what mechanism are you
> claiming that imposes the constraint "it can't invoke sync(2) until
> the first one has finished"?
The code for update() (available in Lions' Commentary on Unix), which
sync() calls, begins with
updlock++;
and ends with
updlock = 0;
This means that a call to sync() could check whether another sync()
is already in progress and could wait to return until it finishes.
Unfortunately, this isn't what actually happens. In fact, if updlock
is set, update() just returns immediately rather than doing anything at
all. So much for the utility of a second sync.
eric
Peter Seebach
David Scheidt <dsch...@enteract.com> wrote:
>Roman Belenov <ro...@nstl.nnov.ru> wrote:
>
>: I've heard that when the second sync command exits, the data will be
>: flushed. Isn't it true, at least on some systems ?
>
>write, and scheduled all dirty buffers for writing. By doing it twice, you
>guaranteed that all dirty buffers were written to disk.
I was told that you did it three times because the time it took to type
this command three times on a slow console was long enough for all the
writes to actually happen.
Richard Shetron
Peter Seebach <se...@plethora.net> wrote:
>In article <7hd4lg$5a8$1...@eve.enteract.com>,
>David Scheidt <dsch...@enteract.com> wrote:
>>Roman Belenov <ro...@nstl.nnov.ru> wrote:
>>
>>: I've heard that when the second sync command exits, the data will be
>>: flushed. Isn't it true, at least on some systems ?
>>
>>I was taught that sync(8) wrote all buffers that had been scheduled for a
>>write, and scheduled all dirty buffers for writing. By doing it twice, you
>>guaranteed that all dirty buffers were written to disk.
>
>I was told that you did it three times because the time it took to type
>this command three times on a slow console was long enough for all the
>writes to actually happen.
>
>-s
>--
>Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
I was told twice for that reason. twice was long enough that by the time
the operator finished typing the second, the first would have finished
so quick operators wouldn't remove power before the writes finished.
Megan
>>I was told that you did it three times because the time it took to type
>>this command three times on a slow console was long enough for all the
>>writes to actually happen.
Which is strange, since I learned to do:
# sync; sync; sync; halt
all on one line...
per the directions for some version of Ultrix
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
fish...@fotd.hosting.netcom.com
>I was told twice for that reason. twice was long enough that by the time
>the operator finished typing the second, the first would have finished
>so quick operators wouldn't remove power before the writes finished.
I wasn't taught that it had anything to do with time,
but simply that the first sync had to return, so the second
one could run, so that you were guaranteed that the first one
had run before shutting down. Like, it would have been
okay to have *any* command in place of the second sync, e.g.,
sync;echo;reboot
--
James
http://ssdd.conservatory.com