Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!unisoft!cjohnson
From: cjohnson@unisoft.UUCP (Christopher Lyle Johnson)
Newsgroups: comp.unix.wizards
Subject: Re: Help: open file limit (Sun-4)
Summary: mmap silliness in pte.h
Keywords: vax, 4.2, mmu
Message-ID: <1937@unisoft.UUCP>
Date: 11 Feb 89 01:52:31 GMT
References: <4813@macom1.UUCP>
Reply-To: cjohnson@binary.UUCP (Christopher Lyle Johnson)
Distribution: na
Organization: UniSoft Systems, 6121 Hollis St., Emeryville, CA 94608
Lines: 36

In article <4813@macom1.UUCP> quester@macom1.UUCP (K. N. Quester) writes:
>
>1. How do I increase the per-process open file limit (beyond 30)?
>

Without source?  Ask Sun.

>2. What is  the meaning of the note in "param.h":
>
>	#define NOFILES	30	/* max number of open files per process */
>	/* Must be <=31, see pte.h */
>
>Should it have been obvious when I looked at pte.h (it wasn't, to me)?
>-- 
>	- Quester (UUCP: grebyn!macom1!quester)

The comment "see pte.h" is an artifact of the 4.2BSD VAX implementation.

The VAX mmu code uses the page table entry to store the block offset of
the backing file (text segment) or swap space (data/stack) for pages
that were paged out.  The pte is marked invalid so the extra bits are
available in these cases.

The vax/pte.h fpte structure is used in this case, and it has a 5 bit
field called 'pg_fileno'.  This field is intended to represent the file
descriptor to load the page from for areas that the process has mmap'ed.
With 5 bits, numbers between 0 and 31 are legal, but if the pg_fileno
field is 0 the page fault was in the text region.  Thus the maximum
number of files mmap'able is 31, and that was the limit on NOFILE.

Of course, the mmap system call was fiction so the comment is slightly
misleading.  In 4.3 the comment was removed, the fpte structure was
changed, NOFILE was bumped up to 64, and mmap was ignored.

					Have fun,
					      cj*