Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!math.fu-berlin.de!uniol!unido!rwthinf!cip-s02.informatik.rwth-aachen.de!u31b3hs
From: u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt)
Newsgroups: comp.os.minix
Subject: Patches to PC MINIX and splitting this group
Message-ID: <4177@rwthinf.UUCP>
Date: 26 Mar 91 12:26:31 GMT
Sender: news@rwthinf.UUCP
Reply-To: u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt)
Organization: Informatik RWTH Aachen
Lines: 44

Hello world,

yesterday I made a cleanup in my kernel/mm files.  I am using PC 1.5.10
MINIX with Gordon Irlam's virtual consoles, Gary Oliver's shared text
segments, Kai-Uwe Bloem's nice scheduler (without profil!) and a third
serial line (AT only - sorry for XTs).  The last patch is my own work
and very simple.  The third serial line uses the same interrupt like a
winchster in XTs, it was the only free interrupt on my card.  It will be
activated by setting NR_RS_LINES to three.  I still have the original
sources, which would allow to make context diffs for a upgrade kit.  I
can include a simple cdiff for login, which allows correct wtmp/utmp
records with terminal minor numbers greater than 9.  If someone is
interested, I will make these diffs and put them on a ftp server.  My
current version (three serial lines, four virtual terminals) needs 165
KBytes, but it allows nice working.

I am unable to reach Gary Oliver via mail.  If modified his mu (memory
used) to work with psdatabase.  Is someone out there who can reach him?

Has anyone tried to increase the number of disk buffers in standard PC
MINIX?  Does it give reasonable speed improvements?

I heard some rumours about bad performance of serial lines in PC MINIX.
It's not true at all.  One of my terminals uses 19200 baud.  I displayed
my german dictionary on it which results in more than 1700 characters
per second (7 data bits, one parity bit, one start and one stop bit)
equals more than 17000 baud *effective* transfer rate.  Sounds like good
performance to me.  These values are measured on a 386 machine with the
provided assembler drivers.

I vote for comp.os.minix.splitgroups.  It seems that this discussion
comes up each year with increasing length :-(.  Most faq's can be
answered by a regular posting of the MINIX information sheet.  *This*
will reduce net bandwidth.  I would not like a moderated MINIX group.
Subgroups for the different machines are bad, because it encourages
machine specific things.  The only argument for splitting this group may
be to easy automatic archiving.  What about comp.os.minix[.disc] and
comp.os.minix.arch? The archive group contains only articles, which the
author wants to be archived, because they contain sources, patches or
important documents, the discussion group contains anything else.

Namaskaar

Michael Haardt