| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Now we can do a simple context swap (without scheduler though)
|
| |
|
|
| |
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| |
|
|
|
| |
not yet wrapped with fmt macros because I want some thing stateless.
(i.e. I don't want to pass `&mut self` to write_str...).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'll implement my own allocator later. Currently using linked-list
allocator [1] to manage the kernel heap (as in kmalloc, not vmalloc). It
manages the ID-mapped region (from VA 0xffff_8000_0000_0000). This
allocator is initialized to use the _largest_ physical memory block. If
the kernel image (text and data) live in this zone then skip the
occupied part.
Key difference between kmalloc and vmalloc:
- kmalloc pretty much manages the physical memory: the allocated address
are within the id-mapped region (see above) therefore the allocated
memory must also be contigous in physical memory. Such memory MUST NOT
page fault. This is prone to fragmentation, so do not use kmalloc to
allocate big objects (e.g. bigger than one 4k page).
- vmalloc manages kernel heap memory and the mapping is managed by
paging. Such memory could trigger pagefault in kernel mode.
Note that the kmalloc conflicts with the previous used stack based PMA
as they operates on the same VM zone.
References: [1] https://github.com/rust-osdev/linked-list-allocator
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| |
|
|
| |
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| |
|
|
| |
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. allow unexpected cfgs in lib.rs, in this case
"no_global_oom_handling" is cause warnings [1]
2. for large code models the compiler (rust linkers) now put code and
data in `.ltext`, `.ldata`, `.lbss`, `.lrodata` instead of the
same `.text` , `.data` ... etc. We are adjusting accordingly in the
linker script.
3. unsafe assertions identified undefined behaviours, in this case a repr(C)
struct was not mared as repr(packed), therefore having an unexpected
size. The unsafe assertions was not enabled by default in debug
builds so the idt setup code with from_raw_parts_mut() has been
working on UB. Glad we can catch this....
related: [1] https://github.com/rust-lang/rust/pull/123501
related: [2] https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html#asserting-unsafe-preconditions
|
| |
|
|
| |
Also renamed a few symbols to avoid confusion.
|
| |
|
|
|
|
|
|
|
|
| |
the x86_64 crate is pretty solid and has a permissive license
(Apache/MIT), but I want to make this myself in the future to
"experience" the unsafe rust further....Also it has too many
abstractions, which is justified as a library, but not ideal for a from
sctrach toy OS as it hides the lower end.
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| |
|
|
|
|
|
| |
use 8MiB reserved array to manage up to 4GiB of physical memory
(4K Pages only)
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| |
|
|
| |
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| |
|
|
| |
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| |
|
|
|
|
|
|
| |
well, it's not trivial to use bios function because thanks to grub +
multiboot, we are already in protected mode when the startup code takes
control. Also the MB info is easier to play with than BIOS (or ACPI)
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
works on qemu, untested on real machine
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The rust lazy_static requires interior mutability. I have to include a
Mutex impl (spin::Mutex). But I'd like to implement my own primitives.
|
| |
|
|
|
|
| |
to make the linter shutup.... You stupid linter, this is a new project!
ofc there are stuffs defined not used.... I'll let you do the job when I
finish... :(
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
