----------------------------------------------------------------------
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Linux-Activists - KERNEL Channel digest. 94-9-19-6:34
Date: Thu, 20 Oct 1994 09:36:42 +0200 (BST)
Steve writes (on scheduling):
> In other words, we'd have these classes of terminal association:
> 1) session leader
> 2) on a tty, but not session leader
> 3) disassociated from any tty
Many many processes are not associated with a terminal and are interactive
in their patterns (inetd, telnetd, rlogind - and not just network programs).
Many terminal programs are definitely large batch jobs (g++). I don't believe
a tty is a good hint.
The important one is getting I/O bound processes run so that they can do
another I/O request and go back to sleep ASAP. This improves their
throughput at little cost.
Another requirement that is important is that the scheduler be as close
to taking no time as possible each schedule. Since policy has to be
evaluated at sufficient rate to cope with the fast changing needs of the
system it also has to be fast, or if its slow it loses the ability to handle
fast changing situations and the low level schedule() has to cover those
cases.
Sven writes (on mice):
> Yes, i agree. Still a user mode mouse server would have problems to serve
> applications running in a different environment than itself.
> This means iBCS and VM86 and who knows what else.
>
> > dosemu could be made to talk to a user-mode mouse server.
> Please enlighten us how !
Use a bus mouse driver. Bus mice read basically X,Y,button state every n
times a second. X,Y,button state is also what comes from the mouse server 8)
Alan
------------------------------
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Rsend
Date: Thu, 20 Oct 1994 09:59:52 +0200
> From: longyear@netcom.com (Al Longyear)
> Subject: Re: tcpdump seg fault?
> Date: Wed, 19 Oct 1994 10:49:53 -0700
>
> >Just wondering.. I'm still getting this since early 1.1 (I think)..:
> You should still get it with 1.1.54! This bug has not been fixed in that
> version either.
It, assorted bugs - including the invalid socket inode bug (that was a good
one) and support for SIGIO are on their way to Linus now.
Alan
------------------------------
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Linux-Activists - NET Channel digest. 94-9-20-8:32
Date: Thu, 20 Oct 1994 14:59:01 +0200 (BST)
> From: stevek@midnite.roslyn.ny.us (Steve Kann)
> Subject: recvfrom: connection refused
> I have been having this "problem" for (at least) as long as I've been using
> slackware 1.2 based Linux systems, and I guess I've finally got to the
> point where I can't look for the error any more, and it is really
> getting to me..
>
> These are the most common, I get hundreds of these each day:
> Aug 9 18:58:30 gary named[20268]: recvfrom: Connection refused
BSD based programs often log udp recvfrom errors. As BSD incorrectly doesn't
report the ICMP unreachable but Linux does it right you get these logged.
Just clobber the message and recompile named.
Alan
------------------------------
End of NET Digest
*****************
-------