chariotos / chariot Goto Github PK

The current implementation leaves a lot to be desired - and an implementation like dlmalloc that uses fixed chunks would allow me to remove the need for the kernel sbrk structure that complicates the memory model.

Also, the current malloc in the kernel is very out of date, cause I wrote it in my 2nd year systems class. It's got bugs in it (like some corruption)

/dev/console should use something a little simpler than a fifo buffer, so it can early return when the user is done entering a line

Userland programs are not implemented yet, but in theory a framebuffer could be given to a user process (like a windowing system) by using a double-buffered system within the kernel.

When the user opens the framebuffer, maybe open("/dev/vga", ...) they might mmap it so they can write to it. Changes to that region will not make a difference on the screen as the kernel double buffers. In order to flush the buffer, the process could do something like an ioctl call to the vga file descriptor like ioctl(vga_fd, VGA_FLUSH) to flush the buffer.

not http tho, gemini.

;)

https://github.com/nickwanninger/chariot/blob/d2a0574c088f5990fc668f14f2f4713f9acf25ab/include/chariot/sem.h#L33

Currently, tasks are too tied to processes, and I feel like having a "schedulable" type of object much like linux's task_struct where the task struct just has a reference to the process table via a pid and in the process table there are POD structs that expose all the information you would need for a process.

For example::

struct process_state {
    int pid;
    int nthreads; // not sure
    /* ... */
    int uid, gid; // etc, permission bits.
    ref<fs::vnode> cwd; // working directory
    vec<file_desc> file_descriptors;
    mutex_lock lock;
    vm::addr_space address_space;
    /* ... */
    // every process has some threads. [0] is the main thread.
    vec<unique_ptr<thread>> threads;
};

struct thread {
    int pid; // the process id the thread belongs to.
    int tid; // the thread id, so we can identify all threads quickly.
};

When threads are created, they are 'cloned' or something from the current process and increment the number of threads the process owns. When the thread dies, it decrements the number. When the process needs to die, it needs to somehow be able to kill all the threads in it's group, so there needs to be a way to look up all the threads that are in a certain process...

We need to store all the threads and pids in tables that allow fast lookup by id. Probably just map<int, unique_ptr<process_state>> which holds ownership and map<int, thread*> which holds pointers, since the tasks are owned by the process it belongs to.

I'm not really sure if this is the best idea, but looking into the linux kernel it makes me feel like it is...

Another way would be much like it is now, but processes are put on the scheduler queue, and a mini-scheduler is located within the process to decide on a thread. This idea sounds okay, but it relies on a little more work in the scheduler than I want.

Currently, the term::terminal feed implementation scales very poorly with significant throughput. It should be replaced with one that does not need to fully move all scrollback when the terminal scrolls.

The current device driver model is old, and feels like linux too much. Replacing it with a more OOP model would probably clean up the code significantly. I think there should be a base class for DeviceDriver, and you can either extend from that or the three kinds of drivers, BlockDriver, CharDriver, or VideoDriver. DeviceDriver would have a method probe() which would hand you a kind of device (PCIDevice, MMIODevice, etc..) and the driver can decide to take ownership of it or not. This would require a change to the internal device model, but that may be required to get pci working on riscv anyways.

In order to do this, there will need to be an interface to notify the system that a new device has been found, that then goes through all the active drivers and checks if they are interested or not. This also allows for hot-plug devices like USB drives in the future. This change will require a rewrite of most drivers, but that can be done slowly, as the x86 platform boots with only the ATA driver loaded.