Date: Wed, 25 Oct 1995 14:14:27 -0700 (PDT) From: John Dyson <dyson> To: terry@lambert.org (Terry Lambert) 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 Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Message-ID: <199510252114.OAA16054@freefall.freebsd.org> In-Reply-To: <199510252047.NAA19391@phaeton.artisoft.com> from "Terry Lambert" at Oct 25, 95 01:47:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510252114.OAA16054>