toor / lambdaos Goto Github PK
View Code? Open in Web Editor NEWA very basic operating system written in Rust, with some sprinklings of Assembly.
License: GNU General Public License v3.0
lambdaos's People
Contributors
Stargazers
Watchers
lambdaos's Issues
Base pointer is zero after process creation
We need to set the base pointer register during process creation. Otherwise, we will eventually run into page faults due to a bad initial rbp value of zero.
For example, mov %rax,-0x18(%rbp), where rbp = 0x0 will have us access the memory location of 0x0 - 0x18 = 0xffffffffffffffe8. The reason this issue came up is because I recently changed bootloaders and page protection is properly setup for my kernel now.
I fixed the issue in rxinu in this commit. I would submit a patch for you but it is late and I don't have my dev environment setup 😄
Notes on further rxinu scheduling changes
I finally merged my scheduling code into rxinu's master branch and wanted to leave some notes regarding my final changes and thoughts on some experimental portions of my scheduler. I hope my code has been working for you so far!
Bug: Freeing the allocated kernel stack
This issue was the culprit of some strange errors I have seen while testing the scheduler. Simply setting the kstack to None does not deallocate the processes's kernel stack. I discovered this issue while testing a process creation cycle where ProcessA calls create(ProcessB) and ProcessB calls create(ProcessA). While running this test, I would hit strange behavior that resulted in page faults and double faults because the incorrect kstack pointer would be freed or memory wasn't actually allocated.
The issue was fixed by calling drop on &mut kstack
Experimental dynamic dispatch
I went back and forth on whether I should include the experimental scheduler dynamic dispatch in the process return. I ultimately decided to keep it in since it works and it can be easily removed if it's determined unnecessary. Since this aspect of the scheduler is not thoroughly discussed in my code, I'll leave some notes here.
To provide context, I initially avoided a global scheduling object because I generally view singletons as a last resort. Though I eventually decided that the singleton pattern fit our use case, the majority of my scheduler code was written with the mindset that an arbitrary number of schedulers could be created and used to schedule processes independently of each other.
One of the challenges I faced with this design choice was killing the process in its process_return function. The self reference to the scheduler object is lost after context switching to a new process in resched(). So when we jump from the new process to process_ret(), we have no access to the original scheduler object and therefore could not call self.kill() or manipulate the proper scheduler's ProcessList. My solution was to push a pointer to the scheduler object onto the kernel stack, pop the pointer off the kernel stack in process_ret(), and convert the pointer into a trait object. Dynamic dispatch is then used to call the getid() and kill() methods.
One limitation of my initial solution is that it assumes the scheduler object is a CoopScheduler. I have fixed that in this commit. Now, the kill() method is agnostic of scheduler type.
Cursor still doesn't work properly.
Look into how to fix this.
commit [1c8701f] fails to compile
stefan:[~/sources/lambdaOS]$ make -j10
make: *** No rule to make target 'target/x86_64-lambda/debug/liblambdaOS.a', needed by 'build/kernel-x86_64.bin'. Stop.
make: *** Waiting for unfinished jobs....
Compiling bit_field v0.7.0
Compiling once v0.3.3
Compiling bitflags v1.0.1
Compiling siphasher v0.2.2
Compiling spin v0.4.6
Compiling volatile v0.1.0
Compiling byteorder v0.5.3
error: Error loading target specification: Could not find specification for target "x86_64-lambda"
|
= help: Use `--print target-list` for a list of built-in targets
error: Error loading target specification: Could not find specification for target "x86_64-lambda"
|
= help: Use `--print target-list` for a list of built-in targets
error: Error loading target specification: Could not find specification for target "x86_64-lambda"
|
= help: Use `--print target-list` for a list of built-in targets
error: Error loading target specification: Could not find specification for target "x86_64-lambda"
|
= help: Use `--print target-list` for a list of built-in targets
error: Could not compile `once`.
warning: build failed, waiting for other jobs to finish...
error: Could not compile `bitflags`.
warning: build failed, waiting for other jobs to finish...
error: Could not compile `siphasher`.
warning: build failed, waiting for other jobs to finish...
error: Error loading target specification: Could not find specification for target "x86_64-lambda"
|
= help: Use `--print target-list` for a list of built-in targets
error: Could not compile `bit_field`.
warning: build failed, waiting for other jobs to finish...
error: Error loading target specification: Could not find specification for target "x86_64-lambda"
|
= help: Use `--print target-list` for a list of built-in targets
error: Could not compile `volatile`.
warning: build failed, waiting for other jobs to finish...
error: Could not compile `spin`.
warning: build failed, waiting for other jobs to finish...
error: build failed
make: *** [Makefile:49: kernel] Error 101
default virt-manager "generic" profile fails to boot
Running the command:
objdump -C -d kernel-x86_64.bin | grep -B50 "122a11:"
outputs:
12297d: 48 89 45 f8 mov %rax,-0x8(%rbp)
122981: 48 8b 45 f8 mov -0x8(%rbp),%rax
122985: 48 83 c4 20 add $0x20,%rsp
122989: 5d pop %rbp
12298a: c3 retq
12298b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
0000000000122990 <core::sync::atomic::AtomicUsize::load>:
122990: 55 push %rbp
122991: 48 89 e5 mov %rsp,%rbp
122994: 48 83 ec 20 sub $0x20,%rsp
122998: 40 88 f0 mov %sil,%al
12299b: 48 89 7d f0 mov %rdi,-0x10(%rbp)
12299f: 88 45 ff mov %al,-0x1(%rbp)
1229a2: 48 8b 7d f0 mov -0x10(%rbp),%rdi
1229a6: e8 e5 65 ff ff callq 118f90 <<core::cell::UnsafeCell<T>>::get>
1229ab: 48 89 45 e8 mov %rax,-0x18(%rbp)
1229af: 48 8b 7d e8 mov -0x18(%rbp),%rdi
1229b3: 0f b6 75 ff movzbl -0x1(%rbp),%esi
1229b7: e8 64 48 01 00 callq 137220 <core::sync::atomic::atomic_load>
1229bc: 48 89 45 e0 mov %rax,-0x20(%rbp)
1229c0: 48 8b 45 e0 mov -0x20(%rbp),%rax
1229c4: 48 83 c4 20 add $0x20,%rsp
1229c8: 5d pop %rbp
1229c9: c3 retq
1229ca: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
00000000001229d0 <core::sync::atomic::AtomicUsize::store>:
1229d0: 55 push %rbp
1229d1: 48 89 e5 mov %rsp,%rbp
1229d4: 48 83 ec 20 sub $0x20,%rsp
1229d8: 88 d0 mov %dl,%al
1229da: 48 89 7d e8 mov %rdi,-0x18(%rbp)
1229de: 48 89 75 f0 mov %rsi,-0x10(%rbp)
1229e2: 88 45 ff mov %al,-0x1(%rbp)
1229e5: 48 8b 7d e8 mov -0x18(%rbp),%rdi
1229e9: e8 a2 65 ff ff callq 118f90 <<core::cell::UnsafeCell<T>>::get>
1229ee: 48 89 45 e0 mov %rax,-0x20(%rbp)
1229f2: 48 8b 75 f0 mov -0x10(%rbp),%rsi
1229f6: 48 8b 7d e0 mov -0x20(%rbp),%rdi
1229fa: 0f b6 55 ff movzbl -0x1(%rbp),%edx
1229fe: e8 6d 49 01 00 callq 137370 <core::sync::atomic::atomic_store>
122a03: 48 83 c4 20 add $0x20,%rsp
122a07: 5d pop %rbp
122a08: c3 retq
122a09: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
0000000000122a10 <core::sync::atomic::AtomicUsize::fetch_add>:
122a10: 55 push %rbp
122a11: 48 89 e5 mov %rsp,%rbp
Handle all exceptions.
We should handle every exception that we can. The advantage of this in debugging is that missing exception handlers will be a non-issue, and therefore we won't run into double faults caused by exception -> missing handler -> pf -> double fault
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.