caltry/bikeshed

Bikeshed is an operating system being re-written in Node.js

bikeshed's Issues

Ext2: Support for indirect blocks

It'd be nice to be able to read files larger than 12KiB.

Pad the output to a 512-byte alignment

To make the bootloader code simpler make FancyCat pad to the next 512-byte boundary

ext2: Can't read files in root directory

We can read files in subdirectories, but not files in the root directory. So, we can read '/etc/motd' but we can't read '/test.txt'.

This is a problem with the way that I do directory traversals.

C++ Virtual Methods Destroy Everything

Compiling in a C++ class with virtual methods causes the system to not boot (dies once paging is enabled).

Update __kmalloc()'s pages between processes

Making this issue so I don't forget. Basically when mapping pages to the kmalloc address space I should switch to the __virt_kpage_directory page directory, do the mapping and switch back. This way if the pages get out of sync between processes I have a master page directory that I can reference and then copy those entries back to the faulting process.

Makedepend warnings

makedepend: warning: startup.s, line 1: unknown directive == "# 1 "startup.S""
makedepend: warning: startup.s, line 2: unknown directive == "# 1 """
makedepend: warning: startup.s, line 3: unknown directive == "# 1 """
makedepend: warning: startup.s, line 4: unknown directive == "# 1 "startup.S""
makedepend: warning: startup.s, line 5: unknown directive == "# 20 "startup.S""
makedepend: warning: startup.s, line 6: unknown directive == "# 1 "bootstrap.h" 1"
makedepend: warning: startup.s, line 7: unknown directive == "# 21 "startup.S" 2"
makedepend: warning: startup.s, line 8: unknown directive == "# 51 "startup.S""
makedepend: warning: startup.s, line 109: unknown directive == "# 159 "startup.S""
makedepend: warning: startup.s, line 139: unknown directive == "# 224 "startup.S""
makedepend: warning: startup.s, line 142: unknown directive == "# 236 "startup.S""
makedepend: warning: startup.s, line 166: unknown directive == "# 268 "startup.S""

Only on makedepend.mk creation

ext2_raw_read() - Doesn't fill buffer properly

Upon further investigation it appears something odd happens if you try to read more than 0x399 (921) bytes using ext2_raw_read(). If I try to read more than that at one time no data is put into the buffer, or splotches of data (don't seem to be relevant to what I want though).

For example:

    void* buffer = __kmalloc(5388);
    ext2_status = ext2_raw_read(bikeshed_ramdisk_context, file_name, buffer,
            &bytes_read, 0, 0x399);
    serial_printf("Buffer at: %x - reading: 5388 - read: %d\n", buffer, bytes_read);
    asm volatile("hlt");

(I narrowed this issue down, because it was failing to read the whole file in one go, which is what the 5388 byte header is for)

If I change the amount to read from 0x399 to 0x400 I fail to get the ELF header. Whatever is causing this is causing the issue with the ELF program sections failing to read, because those are over 0x400 bytes. Any idea why this may be happening?

Probably want some output...

---Elf: attempting to open: /etc/initproc
ELF header location: D0000620
read_ext2.c:667, dirname before excluding filename: /etc/initproc
read_ext2.c:671, dirname after excluding filename: /etc/
get_file_from_dir_path( /etc/, initproc )
read_ext2.c:245 context->sb: E0000400
Feching inode 2
inode_table: E0001400
read_ext2.c:511
get_file_from_dir_inode(etc)
read_ext2.c:536 trying file: . <2>, with length: 1  strncmp(): 55
dirent->entry_length: 12 correct length? 1
read_ext2.c:536 trying file: .. <2>, with length: 2  strncmp(): 55
dirent->entry_length: 12 correct length? 1
read_ext2.c:536 trying file: lost+found <11>, with length: 10  strncmp(): -7
dirent->entry_length: 20 correct length? 1
read_ext2.c:536 trying file: test.txt <12>, with length: 8  strncmp(): -15
dirent->entry_length: 16 correct length? 1
read_ext2.c:536 trying file: etc <13>, with length: 3  strncmp(): 0
dirent->entry_length: 12 correct length? 1
fetching new dir inode: 13
read_ext2.c:245 context->sb: E0000400
Feching inode 13
inode_table: E0001400
read_ext2.c:245 context->sb: E0000400
Feching inode 13
inode_table: E0001400
read_ext2.c:511
get_file_from_dir_inode(initproc)
read_ext2.c:536 trying file: . <13>, with length: 1  strncmp(): 59
dirent->entry_length: 12 correct length? 1
read_ext2.c:536 trying file: .. <2>, with length: 2  strncmp(): 59
dirent->entry_length: 12 correct length? 1
read_ext2.c:536 trying file: welcome <14>, with length: 7  strncmp(): -14
dirent->entry_length: 16 correct length? 1
read_ext2.c:536 trying file: initproc <15>, with length: 8  strncmp(): 0
dirent->entry_length: 16 correct length? 1
read_ext2.c:245 context->sb: E0000400
Feching inode 15
inode_table: E0001400
going to read 52 bytes
read_ext2.c:667, dirname before excluding filename: /etc/initproc
read_ext2.c:671, dirname after excluding filename: /etc/
get_file_from_dir_path( /etc/, initproc )
read_ext2.c:245 context->sb: E0000400
Feching inode 2
inode_table: E0001400
read_ext2.c:511
get_file_from_dir_inode(etc)
read_ext2.c:536 trying file: . <2>, with length: 1  strncmp(): 55
dirent->entry_length: 12 correct length? 1
read_ext2.c:536 trying file: .. <2>, with length: 2  strncmp(): 55
dirent->entry_length: 12 correct length? 1
read_ext2.c:536 trying file: lost+found <11>, with length: 10  strncmp(): -7
dirent->entry_length: 20 correct length? 1
read_ext2.c:536 trying file: test.txt <12>, with length: 8  strncmp(): -15
dirent->entry_length: 16 correct length? 1
read_ext2.c:536 trying file: etc <13>, with length: 3  strncmp(): 0
dirent->entry_length: 12 correct length? 1
fetching new dir inode: 13
read_ext2.c:245 context->sb: E0000400
Feching inode 13
inode_table: E0001400
read_ext2.c:245 context->sb: E0000400
Feching inode 13
inode_table: E0001400
read_ext2.c:511
get_file_from_dir_inode(initproc)
read_ext2.c:536 trying file: . <13>, with length: 1  strncmp(): 59
dirent->entry_length: 12 correct length? 1
read_ext2.c:536 trying file: .. <2>, with length: 2  strncmp(): 59
dirent->entry_length: 12 correct length? 1
read_ext2.c:536 trying file: welcome <14>, with length: 7  strncmp(): -14
dirent->entry_length: 16 correct length? 1
read_ext2.c:536 trying file: initproc <15>, with length: 8  strncmp(): 0
dirent->entry_length: 16 correct length? 1
read_ext2.c:245 context->sb: E0000400
Feching inode 15
inode_table: E0001400
going to read 921 bytes
Buffer at: D0000658 - reading: 5388 - read: 921

Ignore the

Buffer at: D0000658 - reading: 5388 - read: 921

It 'read' the correct amount, but no data was placed into the buffer

Directory traversals don't fail properly

When searching a directory for an entry which does not exist, stop scanning when we reach the end of the directory entry. Consequently, we can sometimes end up reading a file in the wrong directory (like reading '/etc/test.txt' rather than '/foo/test.txt').

What happens:

get_file_from_dir_inode(tfdskjlest.txt)
read_ext2.c:521 trying file: . <2>, with length: 1  strncmp(): 70
read_ext2.c:521 trying file: .. <2>, with length: 2  strncmp(): 70
read_ext2.c:521 trying file: lost+found <11>, with length: 10  strncmp(): 8
<12>, with length: 8  strncmp(): 1xt
read_ext2.c:521 trying file: etc <13>, with length: 3  strncmp(): 15
read_ext2.c:521 trying file: . <11>, with length: 1  strncmp(): 70
read_ext2.c:521 trying file: .. <2>, with length: 2  strncmp(): 70
Unable to read '/tfdskjlest.txt', error # 1

What should happen:

get_file_from_dir_inode(tfdskjlest.txt)
read_ext2.c:521 trying file: . <2>, with length: 1  strncmp(): 70
read_ext2.c:521 trying file: .. <2>, with length: 2  strncmp(): 70
read_ext2.c:521 trying file: lost+found <11>, with length: 10  strncmp(): 8
<12>, with length: 8  strncmp(): 1xt
read_ext2.c:521 trying file: etc <13>, with length: 3  strncmp(): 15
Unable to read '/tfdskjlest.txt', error # 1

That is, we're not failing quickly enough. With more debugging data, it's clear that the last entry (in this case 'etc') is way bigger than it could possible be: 946 bytes. The documentation says that we know that we're at the last element when the inode number is 0 -- but it's starting to look like that's not how the ext2 tools behave.

ext2: block_alloc only allocates blocks in its block group

Right now, the block allocator only allocates blocks that are in the block group for the requested block number. While we want to try to allocate blocks there first, we should be willing to get blocks from other groups -- otherwise we're artificially limiting the size of a file when there are still free blocks.

This is a low-priority fix for me.