4 May
2008
4 May
'08
5:19 a.m.
I looked through init briefly and the version from s2.tar.gz is
slightly different than the one in the pdf printout. In the printout
/dev/rk0 is mounted on /usr at boot time. In the s2 version the
string "/usr" is still present, but the call to mount is gone
and so is the "/dev/rk0" string.
The init source is fairly short and shouldn't be too hard to type
in or get from ocr. Has anyone yet worked through the details of
using the V7 compiler to make 0405 binaries? Also has anyone
successfully used a populated /usr on rk0 yet?
Tim Newsham
http://www.thenewsh.com/~newsham/
4 May
4 May
5:31 a.m.
Poked around in the s2 frags and noticed an even newer version of "init"
in frag2. This one uses "sys 38." to get the console switches (v1 and s2
read them directly and our kernel only has syscalls through 33). This one
mounts several disks (rk1, rk2 and rk3 on usr, ssys and crp) and even runs
a bunch of programs (such as /usr/mel/da and /usr/demo/dds)! Also while
its called a fragment, it looks to be a complete source or very near to it.
Tim Newsham
http://www.thenewsh.com/~newsham/
6:29 a.m.
New subject: comparing s1 frags, s2 bits, 1ed and jun72 print out
Some notes about the s1 frags in the 1972_stuff archive in relation
to 1st edition manual, s2 files and the jun72 printout:
- s1 init mounts several filesystems and runs several commands directly.
s2 init doesn't mount anything. init.s in the jun72 printout mounts
/usr. The 1ed manual describes init as mounting an rk disk on /usr.
- init.s uses syscall to get console switches. The s2 init and the
init.s in jun72 printout read them directly.
S1 uses syscall 38. jun72 printout only has syscalls through 33.
1ed manual only lists syscalls through 33 (SYS ILGINS (II)).
- init.s compares with $173030. The 1ed manual and jun72 printout
compare with $73700 as does the init from s2.
- ls.s uses /etc/passwd. 1ed ls.s uses /etc/uids as passwd is not
readable by normal users.
I think this points to the jun72 bits being closely related to 1ed,
the s2 files as being slightly newer, and the s1 frags as being a
bit newer than that.
Tim Newsham
http://www.thenewsh.com/~newsham/
8:18 p.m.
New subject: [Unix-jun72] 0407 binaries on 1ed
I added a patch "aout407.patch" for running a.out binaries in the 1ed
kernel. It could be a little cleaner; if anyone can review it and fix
it up I would appreciate it. I was able to run "as" and "size",
both of which are 0407 binaries.
This patch isn't applied automatically, but I also changed the
"tools/rebuild" script to take a list of optional patches to apply, so now
you can select any set of optional patches on the command line:
$ tools/assemv7 cold
$ tools/assemv7 aout407
$ tools/assemv7 cold aout407 myowncustompatch
Tim Newsham
http://www.thenewsh.com/~newsham/
10:33 p.m.
New subject: [Unix-jun72] 0407 binaries on 1ed
On Sun, May 04, 2008 at 10:18:08AM -1000, Tim Newsham wrote:
I added a patch "aout407.patch" for running
a.out binaries in the 1ed
kernel. It could be a little cleaner; if anyone can review it and fix
it up I would appreciate it. I was able to run "as" and "size",
both of which are 0407 binaries.
Excellent stuff Tim. I've had a quick look; I suspect the existing code:
cmp r5,u.count /
bgt 1f / branch if r5 greater than u.count
mov r5,u.count
checks to ensure that the new a.out is small emough to fit into the
address space left by the executable that called exec(2).
This patch isn't applied automatically, but I
also changed the
"tools/rebuild" script to take a list of optional patches to apply.
That's also a good idea. Thanks Tim.
Warren
5 May
5 May
midnight
New subject: [Unix-jun72] 0407 binaries on 1ed
Excellent stuff Tim. I've had a quick look; I
suspect the existing code:
cmp r5,u.count /
bgt 1f / branch if r5 greater than u.count
mov r5,u.count
checks to ensure that the new a.out is small emough to fit into the
address space left by the executable that called exec(2).
Right, but after it branches it goes ahead and reads anyway(!?)
Thats the part that confused me.. perhaps there's a line or two
missing somewhere in the code here?
Warren
Tim Newsham
http://www.thenewsh.com/~newsham/
1:17 a.m.
New subject: [Unix-jun72] Another RK mount program
On Sun, May 04, 2008 at 10:18:08AM -1000, Tim Newsham wrote:
I added a patch "aout407.patch" for running
a.out binaries in the 1ed
kernel. I was able to run "as" and "size", both of which are 0407
binaries.
Here is an asm program to mount /usr, which assembles with "as". This
replaces my hand-crafted one from yesterday.
Warren
/ rkmnt.s: mount /dev/rk0 onto /usr
/ Assembles with V1 "as" on V1 kernel with 0407 patch
exit = 1.
write = 4.
mount = 21.
mov $1,r0
sys write; rk0; 8.
mov $1,r0
sys write; usr; 4.
sys mount; rk0; usr
sys exit
rk0: </dev/rk0\0>
usr: </usr\0>
1:23 a.m.
New subject: [Unix-jun72] No luck with C compiler yet, but an idea
On Sun, May 04, 2008 at 10:18:08AM -1000, Tim Newsham wrote:
I added a patch "aout407.patch" for running
a.out binaries in the 1ed
kernel. It could be a little cleaner; if anyone can review it and fix
it up I would appreciate it. I was able to run "as" and "size",
both of which are 0407 binaries.
I played around trying to get the last11c C compiler to work, but no luck
yet. I can compile it using Apout and the existing cc, c0, c1, as binaries.
Tim, I suspect that we need to modify the 0407 patch to also clear the
bss area in core. Here are the headers from several binaries
Size of: text data bss
/usr/lib/c0 000407 023324 003574 005700 017614 000000 000000 000001
/usr/lib/c1 000407 016664 011554 003030 010624 000000 000000 000001
/usr/bin/cc 000407 004576 000416 001024 003644 000000 000000 000001
/usr/bin/as 000407 016616 000000 000000 000000 000000 000000 000001
/usr/bin/size 000407 002626 000000 000000 000000 000000 000000 000001
You can see that c0, c1 and cc all have bss areas, but as and size have no
bss areas, which is probably why they work OK.
Cheers,
Warren
1:56 a.m.
New subject: [Unix-jun72] No luck with C compiler yet, but an idea
I played around trying to get the last11c C compiler
to work, but no luck
yet. I can compile it using Apout and the existing cc, c0, c1, as binaries.
Tim, I suspect that we need to modify the 0407 patch to also clear the
bss area in core. Here are the headers from several binaries
The whole userland is zerod before the a.out is loaded. I did find
a bug -- I was setting u.break to text+data+bss when it should have
been core+text+data+bss - any dynamic allocation was probably giving
back incorrect pointers.
I committed the fix but I don't have a good way to test it. I can't
seem to enter a "}" character (or upper case lettes) into the console
so I cant easily type a test C program. Anyone know of a setting to
work around this or to translate ^M into ^J?
Anyway, if you have more problems, please send me a test program and
I'll try to debug it further.
Warren
Tim Newsham
http://www.thenewsh.com/~newsham/
11:01 p.m.
New subject: [Unix-jun72] uppercase input
On Sun, May 04, 2008 at 03:56:57PM -1000, Tim Newsham wrote:
I committed the fix but I don't have a good way
to test it. I can't
seem to enter a "}" character (or upper case lettes) into the console
so I cant easily type a test C program. Anyone know of a setting to
work around this or to translate ^M into ^J?
I put up a couple of kernel patches to fix the } and lowercase problem,
and to speed up console output. I spent some time trying to fix the ^M
problem, without any luck.
Warren
4 May
4 May
6:50 a.m.
On Sat, May 03, 2008 at 07:19:03PM -1000, Tim Newsham wrote:
I looked through init briefly and the version from
s2.tar.gz is
slightly different than the one in the pdf printout. In the printout
/dev/rk0 is mounted on /usr at boot time. In the s2 version the
string "/usr" is still present, but the call to mount is gone
and so is the "/dev/rk0" string.
The init source is fairly short and shouldn't be too hard to type
in or get from ocr. Has anyone yet worked through the details of
using the V7 [assembler] to make 0405 binaries?
It shouldn't be too hard, but I'm not an assembly person, so it's best
that someone else tries. My previous e-mail about the 0405 and 0407 headers,
plus the fact that the 0405 header IS loaded in memory, should be enough.
Also has anyone successfully used a populated /usr on
rk0 yet?
No, but I can create an rk0.dsk image with my mkfs; then in simh I can
do check (no args) which checks both RF and RK filesystems; ditto df.
So it must be close.
As an alternative, it should not be too hard to hand-craft an 0405
a.out which simply mounts /dev/rk0 on /usr.
Cheers,
Warren
P.S s2 frags: yes, some of them are not fragments, but complete files,
even with junk leftover at the bottom of each file.
8:41 a.m.
New subject: [Unix-jun72] Yes, a mount command
I took Brad Parker's suggestion for a simple mount rk0 /usr command,
and modified it as follows:
exit = 1.
write = 4.
mount = 21.
mov $1,r0
sys write; rk0+040020; 8.
sys write; usr+040020; 4.
sys mount; rk0+040020; usr+040020
sys exit
sys exit
rk0: </dev/rk0\0>
usr: </usr\0>
Assemble this with V7 as, to get:
0000000 000407 000050 000000 000000 000074 000000 000000 000000
0000020 012700 000001 104404 040052 000010 104404 040063 000004
0000040 104425 040052 040063 104401 104401 062057 073145 071057
0000060 030153 027400 071565 000162 000000 000000 000000 000002
0000100 000000 000000 000002 000000 000000 000002 000002 000000
0000120 000000 000000 000000 000000 000000 000000 000000 000000
0000140 074145 072151 000000 000000 000001 000001 071167 072151
0000160 000145 000000 000001 000004 067555 067165 000164 000000
0000200 000001 000025 065562 000060 000000 000000 000002 000032
0000220 071565 000162 000000 000000 000002 000043
Now hand-edit the top line with a binary editor to have this:
0000000 000405 000130 000000 000000 000074 000000 010000 010000
This makes it an 0405 executable, and the first 2 instructions become
mov r0,r0, i.e. a NOP.
Copy the a.out into your V1 /tmp directory, and use tools/mktape.py to
rebuild the tape. If you haven't used it before, here is what I did:
tools/mktape.py /usr/local/src/V1/bin/* /usr/local/src/V1/etc/* \
/usr/local/src/V1/tmp/*
Now do tools/assemv7 cold to build a cold kernel, then ./simh.cfg to run it
to make rf0.dsk.
Now run tools/assemv7 with no args to get a warm kernel. Copy rf0.dsk to
rk0.dsk so that you have 2 filesystems. Run ./simh.cfg, login as root,
and you should see /tmp/a.out. Run /tmp/a.out; you should see /dev/rk0
echoed on stdout. I don't know why /usr is not echoed.
Now you can chdir to /usr and do ls -l in there.
Annoyingly, du / only shows / and doesn't traverse into /usr. So I
may have had it working before, but I didn't realise that du was not the
best tool to verify the mount.
Cheers,
Warren
12:54 p.m.
Tim Newsham wrote:
I looked through init briefly and the version from
s2.tar.gz is
slightly different than the one in the pdf printout. In the printout
/dev/rk0 is mounted on /usr at boot time. In the s2 version the
string "/usr" is still present, but the call to mount is gone
and so is the "/dev/rk0" string.
yes, I noticed that. I looked for strings in the binary init and
didn't see /dev/rk0.
The init source is fairly short and shouldn't be
too hard to type
in or get from ocr. Has anyone yet worked through the details of
using the V7 compiler to make 0405 binaries? Also has anyone
successfully used a populated /usr on rk0 yet?
I think you can hack the header with dd.
I have gotten /usr to mount but something it not right. check says it
has files but the mount does something odd and nothing appears under the
mount point.
-brad
5840
days inactive
5840
days old
12 comments
3 participants
participants (3)
-
Brad Parker -
Tim Newsham -
Warren Toomey