quester@macom1.UUCP (K. N. Quester) (02/09/89)
1. How do I increase the per-process open file limit (beyond 30)? 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)
cjohnson@unisoft.UUCP (Christopher Lyle Johnson) (02/11/89)
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*
guy@auspex.UUCP (Guy Harris) (02/12/89)
>>1. How do I increase the per-process open file limit (beyond 30)? >Without source? Ask Sun. And they'll say, with good reason, "the only way to do that is to upgrade to 4.0". See below. >Of course, the mmap system call was fiction so the comment is slightly >misleading. It's non-fiction in SunOS; even before 4.0, it was used for mapping things such as frame buffers into processes' address spaces. You *might*, with source, be able to whack on SunOS pre-4.0 to allow more file descriptors, but to disallow "mmap"ping them; I don't guarantee that this would prevent the system from getting confused. You may, however, have to recompile programs such as "ps" that know the U area is laid out. >In 4.3 the comment was removed, the fpte structure was >changed, NOFILE was bumped up to 64, and mmap was ignored. In SunOS 4.0 the comment was removed, the 4.3BSD virtual memory system was almost completely removed and replaced with a brand new one (the pageout/swapping policy code is still largely 4.3BSD, but little if anything else is), NOFILE was bumped up to 64, and "mmap" was made to work on regular files.