We don't store the error message anymore in BAN::Error.
Instead we store a error code that can be mapped into a string.
This allows BAN::Error to only take 4 bytes instead of 128.
We should also make some kernel initialization just panic instead
of returning errors since they are required for succesfull boot
anyway.
Now after each interrupt we will ask the scheduler to reschedule
if the current thread is the idle thread. This allows semaphore
unblocking to be practically instant when there is only one thread
executing.
Now disk reading is back to ~3 MB/s for single threaded process
Reading is now much slower at ~500 kB/s it was around 3 MB/s.
This is probably mostly due semaphore blocking taking atleast
until next reschedule (1 ms itervals). This will be a problem
as long as we are using only single processor.
I could try to use {READ/WRITE}_MULTIPLE commands, but since
most of the disk reads are 2 sectors (inode block size) this
will at most double the speed.
Most efficient speed up would of course be caching disk access
data and inodes overall.
The API is kinda weird since device reads/writes go from
ATADevice -> ATAController -> ATADevice
but this is for now atleast necessary since ATAController has(?)
to keep all devices from using the disks at the same time
We used to block on all process access. This meant that shell
reading the keyboard input would block all VFS access making disk
accesses practically impossible. We now block only when it is
necessary :)
This was used by the old input system. Currently keyboard layout is
hardcoded to finnish. But it will be reworked as something read from
the filesystem
We now use Device abstraction that will allow us to provide devices
to userspace through /dev. Currently Shell reads from first and only
device (it being PS/2 Keyboard).
We now lock every function within Proccess, just to be sure.
Recursive lock allows us to use lock from the same thread even if
we already have the spinlock locked
We only have to allocate at the beginning of the all functions and
can properly exit before any disk reads if we run out of memory.
This makes development little bit 'harder' since the {read,write}_block
user must allocate a buffer of atleast block_size bytes.
I also made disk access to cause kernel panic on error since the error
handling during file write is something I don't want to think now.
The filesystem can easily corrupt so, I feel like when disk io starts
to fail I'll come back to this.
I had misread the format and the parsing code was incorrect. I also
changed fonts to store unicode codepoints as 32 bit integers, so
every character can be represented
We now read from a filesystem to user provided buffer.
Read sizes are determined by read call.
You should now get file descriptors and do reading through Process::current()
This disables interrupts for the current scope and restores them
after the scope. This is used in kmalloc, since scheduler might
call into kmalloc/kfree, but deadlock if some thread is currently
trying to allocate. This allows us to use kmalloc in Scheduler.
This is a big commit that was kinda hard to split to smaller ones.
Essentially we now look at all the mass storage devices from PCI
and initialize (P)ATA devices. This doesn't provide any more functionality
but better abstractions and everything doesn't have to be on its old
default port that might be different for modern computers.
We currently dont have a fallback font if we cannot get to filesystem
initialization, but that will come later. I can't test on real hardware
for this reason.
Performance of the old kmalloc implementation was terrible.
We now use fixed-width linked list allocations for sizes <= 60 bytes.
This is much faster than variable size allocation.
We don't use bitmap scanning anymore since it was probably the slow
part. Instead we use headers that tell allocations size and aligment.
I removed the kmalloc_eternal, even though it was very fast, there is
not really any need for it, since the only place it was used in was IDT.
These changes allowed my psf (font) parsing to go from ~500 ms to ~20 ms.
(coming soon :D)
Bananymous