caltry / bikeshed Goto Github PK
View Code? Open in Web Editor NEWBikeshed is an operating system being re-written in Node.js
Home Page: http://www.freelists.org/list/bikeshed
Bikeshed is an operating system being re-written in Node.js
Home Page: http://www.freelists.org/list/bikeshed
\~------------------\~_ ______ _ _ _ _ |#|~~~~~~~~~~~~~~~~~|##- | ___ (_) | | | | | |##| |--| |##| | |_/ /_| | _____ ___| |__ ___ __| | |##| |\---/<==> |##| | ___ \ | |/ / _ \/ __| '_ \ / _ \/ _` | |##| /**\\-/-/**\ |##| | |_/ / | < __/\__ \ | | | __/ (_| | |##| \**/ \**/ |##| \____/|_|_|\_\___||___/_| |_|\___|\__,_| --------------------------------------------------------------------------- Bikeshed Version: 0.0.1-pre-alpha1 (Ornery Orange) README Last updated: 05/24/12 --------------------------------------------------------------------------- To build Bikeshed: * run 'make' in your project directory This will make a file named usb.image that can be copied to a usb drive with the dd command. Other make targets: * novideo This makes a version of Bikeshed with the video component disabled. No graphical user programs will run in this mode. * qemu Build a version of Bikeshed suitable for running on qemu * prog.nl (in src/) Namelist of all global symbols, their values, and the program section they're defined in (Text, Data, Bss). * BuildImage (in build/) A program used to patch the system length into the boot sector of the disk.image file. * FancyCat (in build/) A program used to create a payload containg the kernel and other payloads to be placed in memory (like the ramdisk). Creates images compatable with the Bikeshed bootloader. * prog.dis (in src/) A disassembly of the prog.o file - a text version of the binary machine code. Loading additional files: You can load additional files into memory by adding the name of the file and the address where you want it loaded to the end of the FancyCat command in the Makefile.
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
To make the bootloader code simpler make FancyCat pad to the next 512-byte boundary
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.
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.
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.
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
Compiling in a C++ class with virtual methods causes the system to not boot (dies once paging is enabled).
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.
It'd be nice to be able to read files larger than 12KiB.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.