From: Alan Cox <alan@linux.intel.com>
Date: Thu, 19 Oct 2017 20:08:57 +0000 (+0100)
Subject: projects: longer term kernel projects for someone
X-Git-Url: https://git.ndcode.org/public/gitweb.cgi?a=commitdiff_plain;h=65bb55efc5e8b18652658bc1ffa1f87a78b9640c;p=FUZIX.git

projects: longer term kernel projects for someone
---

diff --git a/Kernel/PROJECTS b/Kernel/PROJECTS
new file mode 100644
index 00000000..7f9f66c3
--- /dev/null
+++ b/Kernel/PROJECTS
@@ -0,0 +1,144 @@
+## Bigger Projects For Anyone Wanting A Challenge
+
+
+
+# Move more data out of the kernel
+
+On a banked 16bit system we have the buffer cache in the kernel address space,
+despite the fact that the kernel doesn't make heavy use of it internally.
+
+Adding the facility to move it out of kernel address space would require some
+simple helpers of the form
+
+	uint8_t *p = bufdata(buf, offset, len); /* len guaranteed <= 64 */
+
+and which would #defined to just return (buf + offset) for simple setups, plus
+modifications to the logic to update directory entries, read/write inodes and
+deal with superblocks.
+
+The trickier bits I can think of are
+- tmpbuf needs to change to be paired with a tmpfree so that the tmpbuf and
+  buf cache linkage becomes optional.
+- we'd need to put back a separate cache of superblocks (as UZI had). That's
+  actually probably a good idea anyway. Removing it may have been a mistake.
+- the user copy routines would need a form that copied data between bufcache
+  and user direct in buffer sized chunks
+
+Getting the buffers out of kernel would allow more buffers and a better balance
+on a 512K machine for example, as we can then have more inodes (which right
+now is our most critical constraint), and more processes.
+
+Keeping inodes out of the main address space is *much* hairier and may not make
+sense
+
+# Better file system options
+
+The V7 like file system works well for tiny boxes as it consumes little RAM
+for state - but is limited to 32Mb, doesn't do block layout well and has
+some known corner cases - such as when the superblock cache is just sitting on
+the limit and keeps spilling in and out of a buffer.
+
+For V7 like we could benefit from
+- sorting the blocks in the superblock list (but remember the head points to
+  the next block of entries so is sacrosanct, or we keep a separate tag of it)
+- handling the block list with some kind of buffering - say having 10 more
+  entries in the superblock cache so we can reduce the thrashing cases
+- support 1K and 4K blocks for bigger machines at the fs level combined with
+  a 32bit block number so that we can get faster I/O and larger volumes. Maybe
+  even adopt S51K format ?
+
+# Bigger Machine Features
+
+There are various things bigger systems want that conflict with the existing
+simple model
+
+- A common model of swap for large processes rather than fixed size slices
+- Disk I/O lookahead so we load multiple sectors if they are the same physical
+  file
+
+	algorithmically
+
+	n = bmap(offset);
+	len = 1;
+	while(bmap(offset + BLKSIZE)) == n + 1 && len < 4) {
+		n++;
+		len++;
+	}
+
+  (and even more so for userspace bulk reads like program load)
+
+- Networking in kernel or in another bank of kernel not via userspace
+
+- Maybe an alternative file system option or vfs
+
+- Smarter scheduler
+
+- VT100 console
+
+# Better Memory Model
+
+Remove the chmem == stack + bss in favour of chmem == stack option.
+
+- Requires relocatable binaries (so we can arrange the stack below the code)
+  bss then grows and bank16k and friends can allocate new banks. Needs work on
+  toolchain. cc65 has an output format with relocations, SDCC's linker does not.
+  For 32bit we use binfmt_flat which has relocations already.
+
+- Split I & D framework for Z280/65C816/PDP11/8086
+
+- Shared code segments for suitable environments
+
+# Graphics
+
+- Add a JITted byte blit or on bigger/better processors bitblit, including
+  screen to screen, host to screen, and pattern blit
+
+- Insert/delete line
+
+- Scrolling region
+
+# Do A Real Implementation of 'Soft' Interrupts
+
+Probably on 68000 boxes. The kernel differentations between di/ei/irqrestore
+and __hard_ methods that are used in specific cases and platform code. We can
+take interrupts outside of the __hard_ cases but must not use the kernel
+calls or stacks.
+
+The irq handler marks any work to be done when irqs are off, and ei arranges
+them to occur.
+
+eg
+
+hw_int(int x)
+{
+	intq |= 1 << x;
+	if (soft_cli)
+		return;
+	intq_run();
+}
+
+ei()
+{
+	__hard_di();
+	while(intq) {
+		__hard_ei();
+		intq_run();
+		__hard_di();
+	}
+	soft_cli = 0;
+	__hard_ei();
+}
+
+or where it makes sense actually do work in the handler first (eg serial FIFO
+buffers that empty into the tty layer when ei is off)
+
+# Executable Formats
+
+We need a sane native object/library/executable format set. One clear option is
+to use a.out as a wrapper and figure out/use the bcc toolchain linker etc.
+
+- What do we want to do about 6502 and ZP relocation - modified o65 ?
+
+Relocatables also means we can in theory do 'shared' libraries to save on disk
+space.
+