Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!news.ececs.uc.edu!news.kei.com!bloom-beacon.mit.edu!howland.erols.net!panix!news.panix.com!not-for-mail From: tls@panix.com (Thor Lancelot Simon) Newsgroups: comp.unix.solaris,comp.unix.bsd.misc Subject: Re: Solaris 2.6 Date: 26 Nov 1996 06:08:26 -0500 Organization: Panix Lines: 95 Distribution: inet Message-ID: <57ej3a$7ij@panix2.panix.com> References: <32986299.AC7@mail.esrin.esa.it> <57djlg$bks@agate.berkeley.edu> <57dkbq$bsr@panix2.panix.com> <casper.329abb76@mail.fwi.uva.nl> Reply-To: tls@rek.tjls.com NNTP-Posting-Host: panix2.panix.com Xref: euryale.cc.adfa.oz.au comp.unix.solaris:90444 comp.unix.bsd.misc:1598 In article <casper.329abb76@mail.fwi.uva.nl>, Casper H.S. Dik <casper@fwi.uva.nl> wrote: >tls@panix.com (Thor Lancelot Simon) writes: > >>In article <57djlg$bks@agate.berkeley.edu>, >>Alan Coopersmith <alanc@godzilla.eecs.berkeley.edu> wrote: >>> * 64-bit file system interfaces (individual files > 2 gigs) based on >>> the API agreed upon at the [6]Large File Summit > >>This is that unbelievably crappy API which made gratuituous changes to basic >>UNIX functionality while conveniently ignoring that 4.4BSD had already >>expanded off_t to 64 bits with little or no difficulty, right? > >That is not quite correct. There's no or little need for recoding >to a new API, but a new API is needed because you can't simply >expand one of the fundemental types of an OS. Oh? And why can't you? This works just fine under 4.4BSD, without causing any applications compiled for the old size to lose. See below. As for newly compiled applications, this is *why* there are all of those typedefs in the header files in the first place -- so that correct code which uses off_t, dev_t, pid_t, &c & so forth won't lose when the type size is changed. And no, naive code won't lose -- that's what prototypes are for. >All you really need is -D_FILE_OFFSET_BITS=64 on the compile >command line. The new API is for internal use of libraries and include >files only, except for code where a distinction between the two types >of open's needs to be made, such as in libraries. There shouldn't be two types of open, period. The 32-bit open (lseek, etc) should remain implemented under its old syscall number, but should vanish from all libraries and include files entirely. Problem solved -- *without* two types of open and all the concomitant lossage, not to mention inelegance. Basically, you guys are ignoring plenty of preexising real-world experience with this issue, and doing something really dumb just because some other vendors are doing so. Would your development organization jump off a bridge if HP's did? I didn't think so. :-) >>Typical commercial-vendor lossage, doing a basic feature exactly the wrong way >>so that they can check off compliance with some awful designed-by-committee >>"standard" that isn't really. > > >Perhaps that is because commercial verndors can't ask there customers: > >"when upgrading from BSD 4.3 to BSD 4.4, all you need to do is recompile >all your code", because that is what it often boils down to. That's false. When the NetBSD kernel moved from a Net2 code base to a 4.4-Lite code base, *no* user code needed to be recompiled to deal with the change in the size of off_t. It doesn't "often" boil down to that, it never boils down to it. The syscall number for "open" was changed, and programs which used the old syscall got the old behaviour -- still do, if the kernel's compiled with COMPAT_43 or COMPAT_09. Mind you, the commercial vendors, as usual, didn't bother to examine actual experience with the research systems before going their merry way; they evidently preferred, as usual, to theorize about it -- incorrectly. >Anotehr important requirement is that non-64 bit offset aware programs >should not be able to manipulate or modify files with sizes overflowing their >idea of off_t. You can't tell in advance whether they're gong to seek or >not, but we don't want them to corrupt data if they do. I'm not following you here. POSIX indicates that lseek takes an off_t as an argument. You seem to be suggesting either that the same syscall number's to used for lseek() by old and new binaries, or that code which explicitly casts the argument of lseek to long (usually by using the constant 0L, in my experience) isn't broken. Again, actual experience porting hundreds of large programs to 4.4BSD indicates that this is essentially a nonissue -- the few erroneous casts are easily enough taken care of, and correct prototypes in the header files ensure that naive programs get lseek()'s seek argument promoted to 64 bits -- and anyone writing new code which explicitly casts lseek's argument to long should, frankly, be taken out back and shot. And the idea that programs should ever _need_ to be "64 bit offset aware" is an abomination all of its own. What happens when you want 128 bit offsets? I guess you go through this all *again*? *Sigh* once upon a time, Sun was one of the "good" Unix vendors, actually paying attention to the results which came out of research systems and acting accordingly. Unfortunately, these days, though Sun does plenty of good research themselves, they seem to suffer from severe (if typical) commercial-vendor NIH. -- Thor Lancelot Simon tls@panix.COM There's nothing like rancid bear fat to keep you happy. -Perry Metzger