- Apr 16, 2017
-
-
Jeremy Soller authored
-
Jeremy Soller authored
-
Jeremy Soller authored
-
Jeremy Soller authored
-
Jeremy Soller authored
-
- Apr 15, 2017
-
-
Jeremy Soller authored
-
Jeremy Soller authored
-
Jeremy Soller authored
-
Jeremy Soller authored
-
Jeremy Soller authored
-
Jeremy Soller authored
-
Jeremy Soller authored
-
- Apr 14, 2017
-
-
Jeremy Soller authored
A faster implementation of the memcpy family
-
pi_pi3 authored
Instead of multiplying everything by 8[/4], now addition is used. That way code is prettier.
-
pi_pi3 authored
The default implementation of the memcpy, memmove, memset and memcmp functions in the kernel file `extern.rs` uses a naive implementation by copying, assigning or comparing bytes ony by one. This can be slow. This commit proposes a reimplementation of those functions by copying, assigning or comparing in group of 8 bytes by using the u64 type and its respective pointers instead of u8. Alternative version for 32-bit architectures are also supplied for future compatibility with x86. Both version first copy whatever they can with wide word types. The tail, i.e. the final few bytes that do not fit in a dword or qword are then copied byte by byte. Here is a comparison of copying 64kiB (65536 bytes) on stack: x86_64-unknown-linux-gnu: (64-bit) | naive (ns) | fast (ns) | speedup (x) -------|------------|-----------|------------ memcpy | 204430 | 32994 | ~6.20 memmove| 202540 | 33186 | ~6.10 memset | 163391 | 23884 | ~6.84 memcmp | 205663 | 34385 | ~5.98 i686-unknown-linux-gnu: (32-bit) | naive (ns) | fast (ns) | speedup (x) -------|------------|-----------|------------ memcpy | 206297 | 66858 | ~3.09 memmove| 204576 | 70326 | ~2.91 memset | 165599 | 50227 | ~3.30 memcmp | 204262 | 70572 | ~2.89 Copying on the heap behaves simmilarly. All tests performed on Intel i5 6600K (4x4.2GHz), ArchLinux Kernel 4.8.12-3 x86_64.
-
Jeremy Soller authored
-
- Apr 12, 2017
-
-
Jeremy Soller authored
- Apr 11, 2017
-
-
Jeremy Soller authored
Fix the listing of `initfs:` directories
-
Nagy Tibor authored
There was a bug at the `initfs` generation which made the listing of the contents of the `initfs:`subdirectories impossible from the command line. The subdirectory listing data had the full paths of the files (like `bin/ahcid\nbin/bgad\n...`) when it should just only be the names of the files (`ahcid\nbgad\n...`)
-
- Apr 09, 2017
-
-
Jeremy Soller authored
Cleanup utf8 path error handling
-
- Apr 08, 2017
-
-
Jeremy Soller authored
-
- Apr 06, 2017
-
-
Jeremy Soller authored
-
Jeremy Soller authored
-
- Apr 05, 2017
-
-
Jeremy Soller authored
Refactor
-
- Apr 04, 2017
-
-
Jeremy Soller authored
-
Jeremy Soller authored
-
- Apr 02, 2017
-
-
Jeremy Soller authored
-
- Mar 27, 2017
-
-
Jeremy Soller authored
Fix spelling & grammar in README.md
-
Adam Niederer authored
-
- Mar 25, 2017
-
-
Jeremy Soller authored
Fix issue with serial and cascade interrupts not being ackd
-
- Mar 22, 2017
-
-
Jeremy Soller authored
Do not initialize waitcondition with capacity
-
- Mar 21, 2017
-
-
Jeremy Soller authored
-
- Mar 19, 2017
-
-
Jeremy Soller authored
-
Jeremy Soller authored
-
Jeremy Soller authored
Implemented reading from RTC Century counter in x86_64 arch, if available
-
- Mar 18, 2017
-
-
Connor Wood authored
Fully implemented reading the RTC century counter, and laid out initial infrastructure for ACPI information to be used across the kernel, in the x86_64 architecture. - Implemented a global variable, ACPI_TABLE, behind a mutex, which contains the ACPI information pertinent to the rest of the kernel, currently solely containing a pointer to the FADT. - Split device initialization into two categories - "core" devices, such as the PIC and local APIC, necessary for initializing the rest of the kernel, and "non-core" devices such as serial and RTC, which are to be initialized last. - Checked for the presence of the century register, and consequentially read from, in the RTC code, now factored into the date calculation. The location of the register is pulled from the "century" field in the FADT. - Modified page unmapping in the ACPI code, such that any tables to be stored globally (currently only the FADT) are not unmapped after reading, such that they can be stored in globally accessible pointers without causing page faults.
-
Connor Wood authored
-
- Mar 17, 2017
-