make keyboard work a bit

report/kernel.tex

@@ -269,16 +269,37 @@ registers and possibly other information which is different per Thread.
 \item Let Iris schedule the next process.  This is not thread-specific.
 \item Get the top Memory object.  This is not thread-specific.  Most Threads
 are not allowed to perform this operation.  It is given to the initial Threads.
-They can pass it on to Threads that need it (mostly device drivers).
+They can pass it on to Threads that need it (if any).
 \item In the same category, register a Receiver for an interrupt.  Upon
 registration, the interrupt is enabled.  When the interrupt arrives, the
 registered Receiver gets a message from Iris and the interrupt is disabled
 again.  After the Thread has handled the interrupt, it must reregister it in
 order to enable it again.
+\item Allocate a range of contiguous physical memory.  This is only relevant
+for device drivers whose device will directly access the storage, such as the
+display driver.  The result of this call is that the memory is counted as used
+by the Thread, and it is reserved, but it is not returned.  Instead, the
+address of physical memory is returned, and the pages need to be retrieved with
+the next operation.  This capability is not present in normally created
+threads.
+\item Allocate a page of physical memory.  This is used in combination with the
+previous operation to reserve a block of physical memory, and by device drivers
+to map I/O memory into their address space.  There is a flag indicating whether
+this memory should be freed (ranges) or not (I/O).  Users of this operation are
+trusted to handle it properly; no checks are done to ensure that no kernel
+memory is leaked, or that the allocated memory isn't used by other threads or
+the kernel.  Of course, this capability is not present in normally created
+threads.
+\item Get the physical address of a page.  Only device drivers need to know the
+physical address of their pages, so this operation is not available on normal
+threads.
 \item And similarly, allow these priviledged operations (or some of them) in an
 other thread.  This is a property of the caller, because the target thread
 normally doesn't have the permission to do this (otherwise the call would not
-be needed).  The result of this operation is a new Thread capability with all specified rights set.  Normally this is inserted in a priviledged process's address space during setup, before it is run (instead of the capability which is obtained during Thread creation).
+be needed).  The result of this operation is a new Thread capability with all
+specified rights set.  Normally this is inserted in a priviledged process's
+address space during setup, before it is run (instead of the capability which
+is obtained during Thread creation).
 \end{itemize}
 
 \subsection{Page and Cappage}
@@ -317,4 +338,14 @@ Operations or capability objects:
 \item Get a copy of the capability.
 \end{itemize}
 
+\section{Interface classes}
+Around Iris is a system of some programs to create the operating system.  These
+include the device drivers.  While Iris itself needs no specific interfaces
+from them, some interface classes are defined, which are used by the default
+environment.  By defining classes, it is possible to let a program use any
+device of that type without needing changes to its code.
+
+These definitions are in the source.  A copy of the information here would only
+lead to it getting outdated.
+
 \end{document}

report/making-of.tex

@@ -578,4 +578,70 @@ Because this didn't feel good, I decided to implement the timer interrupt
 first.  I copied some code for it from Linux and found, as I feared, that it
 didn't give any interrupts.  I suppose the os timer isn't running either.
 
+However, it wasn't as bad.  I simply had a bug in my timer code; the OS timer
+does give interrupts.  Checks to see the random register also showed that while
+it doesn't run as required by the mips specification, it does auto-increment as
+part of the \textit{tlbwr} instruction, which is for practical purposes just as
+good (but, I suppose, costs less power).
+
+So the only clock that isn't working is the cpu counter.  This means that the
+operating system timer must be used for timed interrupts, and that works fine.
+
+After rereading the Linux driver for the display, I also found several things I
+had done wrong, and after fixing them it did indeed work.  The display
+controller reads its data from physical memory, which means that the entire
+framebuffer needs to be a continuous part of physical memory.  I had to create
+a new kernel call for this.  Like the other priviledged calls, I added it to
+the Thread capability.
+
+\section{Debugging made easier}
+So far, all debugging had to be done using blinking LEDs.  This is slow and
+annoying.  With a working display, that was no longer needed.  I added a simple
+($6\cross8$) character set, and implemented a way to let the kernel send
+messages which are printed on the screen.  Then I changed the response to a
+\textit{break} opcode to result in sending a character to the lcd as well.  Now
+I have a textual log output, which is much better than blinking LEDs.
+
+Shortly after this, I encountered a bug in the kernel allocation routines.
+This still needed to be debugged with blinking LEDs, because allocation was
+done as part of sending messages to the display driver.  This was annoying, but
+now that's done as well and the text log can be used.
+
+\section{Keyboard}
+The keyboard driver works mostly as I expected it to.  I added interrupts on
+any change, so that it is quite normal that key changes are detected by
+interrupt, which is faster than waiting for a scan.  I would like to use
+level-triggered interrupts, instead of edge-triggered.  However, at the moment
+that doesn't seem to work.  I don't really care for now, although this may lead
+to missed keys, so it is something to fix eventually.
+
+\section{What is a terminal?}
+Now's the time to think about more high-level features.  One feature I want to
+have is that a user has a session manager.  This session manager can have
+access to the terminal.  And it can lose it.  And get it again.  It gets access
+when the user logs in, and loses it when the user logs out.  Having access
+means being able to use the hardware (display, keyboard, sound, etc.).  The
+problem is mostly with losing the display.  Getting access to the display
+happens by mapping the pages into memory.  The user can then share these pages,
+and it will be impossible to revoke the access.
+
+But there is a simple solution.  The session manager itself is part of the
+system.  It is trusted by the kernel, and will behave.  It will do anything the
+user asks, as long as the system allows it.  Each session manager can have its
+own frame buffer.  This is even a good idea: it means that user programs will
+not have to handle things differently depending on whether the framebuffer is
+available: it is always there, it may just not be visible for the user.  Then
+the rest of the problem is for the user to solve.  The user may mess up their
+own display if they want.  It will not harm the main control display (used by
+session managers and the login manager), or displays of other users.
+
+\section{Defining interfaces}
+The next programs to write are a \textit{block device} (the mmc and sd card
+driver, or else a ramdisk), a file system, the session manager, a keyboard
+translator (interpreting modifier keys and implementing key repeat) and some
+sort of shell.  These are more device \textit{class} interfaces than simply
+interfaces for these specific devices.  So it's good to design an interface for
+the class, which allows other devices of the same class to use the same
+interface.  Then higher level programs can use both devices without noticing.
+
 \end{document}