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.
Bananymous