On Thu, May 01, 2008 at 08:33:35PM -0400, Brad Parker wrote: I was hoping to have a populated filesystem to start with, because we should be able to run V1 bin/check using Apout, to check the filesystem. The V1 manual for filesystem(5) say "Blocks 0 and 1 are collectively known as the super-block for the device". Can you confirm that block 0 is part of the super-block, i.e. it's not reserved for bootstrap code? If block 0 is the super-block, it should contain a word (# of bytes in free-map) followed by lots of 0177 bytes, which are the free-map. On another note, I thought of taking V6 mkfs.c as a start-point to rewrite V1 mkfs. I'm trying to work out what f_m and f_n do: if(fsys[n] == 'r') { if(f == 'k') { f_n = 24; /* RK, why these numbers? */ f_m = 3; } if(f == 'p') { f_n = 10; /* RP, why these numbers? */ f_m = 4; } } Finally, are we going to use RK03 or RK05, as the sizes are different? Thanks all, Warren

On Fri, May 02, 2008 at 10:58:08AM +1000, Warren Toomey wrote: I gave up and decided to write mkfs from scratch :-) I'm a bit baffled on the i-node map and list. The V1 filesystem(5) manual says: I-numbers below 41 (base 10) are reserved for special files, and are never allocated; the first bit in the i-node free map refers to i-number 41. Therefore the byte number in the i-node map for i-node i is (i-41)/8 and offset (i-41)%8 bits from the right... I-numbers begin at 1, and the storage for i-nodes begins at block 2. Also, i-nodes are 32 bytes long, so 16 of them fit into a block. Therefore, i-node i is located in block (i+31)/16 of the file system, and begins 32*((i+31)%16) from its start. I-node 41 (base 10) is reserved for the root directory. Now, I am assuming that this means: a) the i-mode bitmap is missing bits 0 to 40, but b) the actual i-nodes 0 to 40 do exist, and c) the system can still "read i-node 7", even if it can't allocate i-node 7. Following the manual, the root directory i-node is number 41, so its bit in the bitmap is (41-41)/8==0, offset (41-41)%8== bit 0. But the actual i-node used is still i-node 41, so that is on block (41+31)/16==block4, offset 256. Let me know if that sounds right, or if I'm off-base somewhere. Thanks, Warren

I did a little more research on the disks, and added my notes to the machine.txt file. Included below. Looks like we should be able to craft a tape image with a list of files and use the cold boot mechanism to initialize the rf0 disk (which has to be the root fs). We may still want an mkfs for initializing an rf03 later. ---------------- Disks: rf0 - 1024 blocks, always mounted, has root and swap. last 64 blocks (32kbyte) allocated to swap by u0.s u0.s can setup rudimentary fs on this if built with "cold=1" rk0 - 4871 blocks u0.s sets up rf0 as: - superblock layout - free storage map contains 128 bytes - inode map contains 64 bytes - allocate top 64 blocks "to unix" (960..1023) - allocate 17 blocks per process (nproc) (688..960 - 16 procs) - free blocks 687..34 - zero out blocks 33..1 for use as inodes (and 2nd half of superblock which is unused?) - for each special inode i-1 to i-40 initialize it - mode 100017 (allocated, read, write, other read, othe write) - num links = 1 - uid = 1 (yup, not root) - fill in timestamp info - write out premade i-nodes on i-41 .. i-47 with premade directory data. i-41 root (with dev, bin, etc, usr, tmp) i-42 dev (with tty, ppt, mem, rf0, rk0, tap0 .. tap7, tty0..tty7, lpr, tty8) i-43 bin (empty) i-44 etc (with init) i-45 usr (empty) i-46 tmp (empty) i-47 init (binary, included in u0.s) special version that opens /dev/tap0 and reads files from it, creates them, chmods them and chowns them Tim Newsham http://www.thenewsh.com/~newsham/