Date: Wed, 25 Oct 1995 14:35:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dyson@freefall.freebsd.org (John Dyson) Cc: terry@lambert.org, bde@zeta.org.au, 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: <199510252135.OAA19692@phaeton.artisoft.com> In-Reply-To: <199510252114.OAA16054@freefall.freebsd.org> from "John Dyson" at Oct 25, 95 02:14:27 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... 2^12 * 2^31 = 2^43. 2^43 << 2^63. The problem is for large file systems, and a lesser problem, large files on large file systems (lesser because a file will always be smaller than the FS that contains it). Causing the access to the file to be windowed through the available address space would resolve the problem once and for all and put it at 2^63 -- the highest bit still being reserved for error return on lseek and for indirect block identification. Right now it is impossible to support those files for which quad is a desirable type for off_t because of VM limitations imposed. The imposition is present codified in ffs_vmlimits() in the source file /sys/ufs/ffs/ffs_vfsops.c. The only value of quad is as an annoyance and as a spur to further annoyance and standards violations, as well as an advocacy of evil portability sabatoge to the ABI calling interface. The codification in ffs_vmlimits() is an interface violation in any case: it is a machine architecture dependency, and in acutality a vmio dependency and doesn't belong in the supposedly machine independent FS code anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510252135.OAA19692>