From owner-freebsd-hackers  Wed Oct 25 14:14:47 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id OAA16137
          for hackers-outgoing; Wed, 25 Oct 1995 14:14:47 -0700
Received: (from dyson@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id OAA16054
          ; Wed, 25 Oct 1995 14:14:28 -0700
From: John Dyson <dyson>
Message-Id: <199510252114.OAA16054@freefall.freebsd.org>
Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c]
To: terry@lambert.org (Terry Lambert)
Date: Wed, 25 Oct 1995 14:14:27 -0700 (PDT)
Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org,
        bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org,
        hackers@freebsd.org, swallace@ece.uci.edu
In-Reply-To: <199510252047.NAA19391@phaeton.artisoft.com> from "Terry Lambert" at Oct 25, 95 01:47:35 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1644      
Sender: owner-hackers@freebsd.org
Precedence: bulk

> 
> Probably a "correct" approach would be to either (1) push 64 bits per
> for all arguments, using type identification to decide on pushing a 0
> for the quad high order dword or pushing a value that really exists at
> the time of the call, or (2) choose a different violation of the ANSI C
> and POSIX standards -- interface extension -- instead of passing quad's
> for the default truncate/seek/mmap call interfaces.  The additional
> calls would only exist as inlines, not in libc, and would thus be unusable
> without prototypes (qtruncate/qftruncate/qseek/qlseek/qmmap).  And
> you wouldn't even implement qmmap until the vmio file windowing is fixed
> in the kernel VM system.
> 
Terry,
	I am confused whe you talk about file windowing.  There is 
	absolutely NO windowing or mapping of files into the kernel
	space except for reading an executables file header.  Files
	take only the KVA space to support the buffer cache and paging
	I/O.  I believe that there are *totally* broken schemes whereby
	file I/O is done through kernel page faults -- but that is not
	what we do.  All I/O is explicit -- it is nicer that way.

	Pages from files are simply bulk data residing in VM objects.  Some
	of which have buffers associated with them.

	The problem with the addressibility in the lower levels of the VM
	system is that the
	size of a VM offset is a unsigned long.  I do not want to change that
	to a long long for efficiency reasons.  I have a method that
	will keep the size of the data structure mostly the same, and
	give a 2^12 increase in the size of the address space.

	It *might* be a 2.2 thing...

	John
	dyson@freebsd.org