Subject: lib/10279: Large File Summit API is not supported under NetBSD
To: None <>
From: None <>
List: netbsd-bugs
Date: 06/04/2000 18:54:17
>Number:         10279
>Category:       lib
>Synopsis:       Large File Summit API is not supported under NetBSD
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 04 18:55:00 PDT 2000
>Originator:     Dave Sainty
>Release:        NetBSD-current early June
Dynamic Technology Services and Products Ltd (NZ)
System: NetBSD 1.4R NetBSD 1.4R (TEQUILA) #3: Wed Feb 16 20:01:31 NZDT 2000 i386


	The Large File Summit API is (I'm told) supported by recent Solaris's,
	Irix, Linux and possibly others (given the list of companies in
	attendance).  One might question whether the LFS
	approach is correct.  But... not supporting it still
	generates a porting issue with programs that expect the API to be

	On NetBSD the effort required to support the API is fairly minimal.
	Possibly no kernel changes.

	As a sample, the API looks like (from the first URL above): STDIO Interfaces

fgetpos64()            fopen64()
freopen64()            fseeko64()
fsetpos64()            ftello64()
tmpfile64() Other Interfaces

creat64()             fstat64()
fstatvfs64()          ftruncate64()
ftw64()               getrlimit64()
lockf64()             lseek64()
lstat64()             mmap64()
nftw64()              open64()
readdir64()           setrlimit64()
stat64()              statvfs64()

	In our case, they can basically be wrappers for the existing
	functions.  The *64 functions take 'off64_t' instead of 'off_t'
	parameters, which in our case are also the same size.

	This is purely a compatibility issue, I wouldn't suggest encouraging
	the use of these API's inside NetBSD userland programs.

	nm /usr/lib/libc.a | fgrep lseek64

	No fix as yet.