nanogui: pk-0.9.1
Subject:
RE: pk-0.9.1
From:
Greg Haerr ####@####.####
Date:
8 Oct 1999 18:29:42 -0000
Message-Id: <01BF1188.7CBBF360.greg@censoft.com>
: pk has no explicit device model. printf and getchar are implemented as
: system calls under the assumption that there is a single screen. This will
: be problematic first off. There needs to be a way to tie a window to
: a thread for its stdio. Need to think about this one a bit.
Frank - I pulled down your pkos right after I sent the last message,
and now understand where the os is at. So microwindows will basically
be linked in with the kernel. Stdio is is not strictly required, since currently
microwindows doesn't really do file i/o. The printf's are there just for debugging.
Perhaps the microwindows thread can do polling for the keyboard and/or serial
port. (this is just for the v0.1) In this way, you set the .Poll entry point
for the keyboard and serial port to query the os state of the keyboard and
serial port.
If you need various versions of stdio, I have some, but I don't think you need them
: The screen driver can be handled easily. I even had someone donate a
: drawvline routine for the driver today too so I can add that one to the
: next release.
Great. Remember we have all the VGA routines already written,
you can just copy them into your own driver file for pkos. You will want
a hardware palette set routine, for 16 colors.
: Keyboard driver probably needs to be expanded. It only handles shift right
: now, no ctrl or alt or multiple combinations.
Doesn't matter, microwindows uses ESC to exit, else just regular ascii
chars for now
: pk provides an event mechanism that has semantics similar to a barrier.
: You define an event and then threads can wait on it. When the event occurs,
: all waiting threads are scheduled for execution. There is no mechanism
: for a single thread to wait on multiple events simultaneously yet.
This is why you might want to just use a polling mechanism to get it
off the ground. then, you can implement a kernel structure that keeps
a list of waiting threads, and whenever an event is fired, this list is checked
in addition, and if matched, the associated thread is scheduled in addition.
Greg
