Path: utzoo!attcan!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: Some more 1.3 notes
Message-ID: <920@ast.cs.vu.nl>
Date: 20 Jul 88 09:25:57 GMT
References: <4193@ea.ecn.purdue.edu>
Reply-To: ast@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 26

In article <4193@ea.ecn.purdue.edu> housel@ea.ecn.purdue.edu (Peter S. Housel) writes:

[lots of things]

All of Peter's comments seem right on the mark.  I'll incorporate them into
the final version as best I can.

One of them is important enough to mention explicitly, however.  The shell
stack size was changed to 20000 (see tools/changemem) in 1.3 because I
thought that was needed to handle large shar files.  In retrospect, that
may not be the case.  I chmem'ed the shell back to 8K, and it seems to
work.  This is important because with multiple terminals, shervers, and the
like, there are many more shells around than there used to be and the extra
memory consumed is nontrivial.

I would suggest that everyone set the shell stack to 8K and see what happens.
If problems arise, please post a description of them.  If no one runs across
any for a few weeks, I'll use 8K in the final version.

As to chmem of 3072 for small programs, it is possible that the issue here
is a command like ls *.c in, say, commands.  The shell expands *.c into a
long list, and puts in on ls' stack.  If that is too short==>crash.  In 1.2,
ls *.c didn't work in commands; now it does.  Thus I am inclined to follows
Peter's lead and change all the 2K stacks to 3k.

Andy Tanenbaum (ast@cs./vu.nl)