[Unix-jun72] init

[Unix-jun72] init

[Tim Newsham]

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/

[Unix-jun72] init

[Tim Newsham]

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/

[TUHS] comparing s1 frags, s2 bits, 1ed and jun72 print out

[Tim Newsham]

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/

[Unix-jun72] init

[Warren Toomey]

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.

[Unix-jun72] Yes, a mount command

[Warren Toomey]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.out
Type: application/octet-stream
Size: 156 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080504/80d2673e/attachment.obj>

[Unix-jun72] init

[Brad Parker]

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

[Unix-jun72] 0407 binaries on 1ed

[Tim Newsham]

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/

[Unix-jun72] 0407 binaries on 1ed

[Warren Toomey]

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

[Unix-jun72] 0407 binaries on 1ed

[Tim Newsham]

> 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/

[Unix-jun72] Another RK mount program

[Warren Toomey]

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>

[Unix-jun72] No luck with C compiler yet, but an idea

[Warren Toomey]

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

[Unix-jun72] No luck with C compiler yet, but an idea

[Tim Newsham]

> 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/

[Unix-jun72] uppercase input

[Warren Toomey]

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