celtic (Arlen Cuss)

Starting to add queue stuff, now that I've sort of worked it out in my head. For now, just one queue - a 'reply' queue (though it can contain non-reply messages i.e. beginnings).

Reworking the way I'm organising system calls, they're all getting a bit cramped in there. Now it doesn't work, fuck it.

After much deliberation, streams and queues ...

Slightly worrying that I have to put this skip in, but oh well ...

Start on ATA stuff...

Duplicate shells, adding a syscall_exit to the entry since I know it'll fail, and letting the pagefault handler drop back to the interrupt handler so the process gets killed.

Removing ks/utks distinction.

We have a defined user stack now, which is important. Starting to resolve some confusing/ambiguous lines (like "!a > 0"), and realising that the ks/utks distinction may be completely gone/pointless now.

All these statics/globals are living inside the kernel (since it's still all one compilation unit), which means we can't change them from a different ring. Refactoring so everything goes on the stack of the process.

Finding the "proper" way to abort the hell out of the initial task, but we're still getting write errors elsewhere. I'm betting they're stack related.

Turning off kernel heap promiscuity and cleaning up entry.cpp's line breaks. It's dying.

Mallocing works. I've realised we're still running the kernel heap in promiscuous mode, which means I'm being sloppy with memory. Time to fix that. We also have no `free', still, heh heh heh.

This seems improbable, but I think we have per-process heaps. Now to actually try to use them.

Implement memcpy.

Starting to give tasks their own heaps. Japanese comment messing up my terminal :(

Preparing for user-land memory (de)allocation and line-by-line reading in the shell.

Justifying why this works, now that I've tested it for both cpl 0 and 3, and it works, and tried inverting hte logic, and it doesn't! Adding an ASSERT to make sure we didn't somehow get here but still have our call block on us.

Going to actually retry the call from the scheduler.

Encapsulating the behaviour of blocking calls, and of the read call in classes.

Seeing how we can inject data back in. We're also going to have to handle part of the read call in the task manager if we keep this up... something seems wrong about this? Perhaps it's the way I'm doing syscalls.

Slowly introducing blocking node read. I'm muddling up the architecture to do this, but will refactor various task IO blocks later.

List's ++ op was actually returning the ++, not modifying itself. Guess what? IT WORKS NOW.

Added defer, just for programs to pass the buck when they want to. That's probably not so useful, and I'm not even using it now for fear that it's complicating the issue at hand. Something's blowing the heap, I think it's my crapper buffer implementation (or maybe the heap just sucks).

Make the keyboard driver cycle 1mil times just so the shell gets a chance to start. Shell waits until it can grab a listener on the keyboard driver and reports. Works! Omg. :-)

Exposing the User::read/writeNode methods through syscalls, then using that in kb. Untested.

Whoops. Those won't be working with nul-terminated strings, they're just arbitrary buffers. Maybe the code is more fragile now, will test. Added a way to write to nodes.

Adding all sorts of views into the Listener, exposing it through Node and then using that in the readListener syscall.

Listeners get a buffer they can append to.

Need a separate listener object for this (buffers and so on).

Whoops. Left in a old line that made no sense in Symbol's compare op, and left out the iteration in strcmp.

String comparisons aren't going well. Not pulling in all header files for Akari by default - clients now have to include it.

Beginning to have node writers/readers. Adding a symbol type for immutable strings to act as keys.

Fleshing out IPC a little more, getting ready for KB to talk to Shell.