Re: 1.6.1 impressions

[Pavel Machek <pavel@elf.ucw.cz> writes:]

>First: Thanx for 1.6.1. It's really nice. I even tried TCP/IP package, and
>it quite works to my big surprise.

(grin)

>* Seems like process #1 (usually cons) disappears from ps listing after some
>time of heavy activity. (Try rebuilding whole sources.) It is also no longer i
>n
>/proc filesystem.

I've tried this again and again, even under MGR, and don't see it happen.
You'll need to pick apart your proc chain from the kernel debugger, or give
me more clues as to what causes it.

>* telnetd does not work too well for me. 'plain' version justed printed login
>banner and existed immediately, with comment 'IO server: all clients done' in
>syslog. After I patched (nrefs<1) to (nrefs<0), I can log in and work, but it
>will not disconnect at the end.

I can't reproduce this, either. For me telnet works fine for multiple
logins, and "tcp stat" shows correct timeout and cleanup. Also, no funny
reference counts under "vsta stat". I remade from scratch to make sure I ws
using current code.

>* Question: What are reasons behind having processes organized in tree? I have
>thought about putting part of scheduler outside of microkernel (making uKernel
>capable only of strictly-prioritive scheduler, and external daemon, which
>would play with process's priorities based on how much they run). Is there way
>to see tree structure of processes in ps?

The tree gives you a "fair share" distribution of CPU. It was an idea I
wanted to code up, so I put it in VSTa way back when I was first writing it.
I exercised the tree distribution a bit early on (with direct hacking to
make the trees I wanted) and it worked OK. But I never fleshed out a
regular syscall API to control/monitor it.

BTW, the "cheated" queue came as a result of the latency a fair share
allocation imposes on interactive processes. Basically, trees and fair
share are good when you're dealing with CPU-heavy processes, but if a
process takes only small slices at a time (typing to a shell or editor, for
instance) then it suffers unduly if it always has to go back into the tree.

>* ps tries to show some kind of times with each process. This times look like
>min:sec, but they are not. They are running much faster. What is that?

Looks like at a minimum a units problem in pulling the values from pstat. I
played with this a little bit, and still am not satisfied I understand
everything that's going wrong here.

>* here is patch for srv/mach/cons2/isr.c - it makes 'Meta' key work, so
>Alt+letters have good meanings. (Console is unusable for me without this).
>It also simplifies handling of F1, F2, ... keys.

Ok, I think I'll fold this one in.

>* printink 'feel free to hit reset button' on attempt to reboot is
>bad think (tm), because user has to go and push reset button
>himself. On the end, I append simple program to reset machine. I think
>that this should be put in place of reboot script

We probably also want a call into the kernel to do the current shutdown
trick. I've heard of PC's where the keyboard wouldn't work but CR3/shutdown
would, and also vice versa. If we do both, we're probably pretty safe.
I'll play with this, too, unless you want to.

>Keep hacking,

Always.

                                                        Andy
Received on Fri Feb 13 06:36:16 1998