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!feed1.news.erols.com!howland.erols.net!EU.net!sun4nl!fwi.uva.nl!not-for-mail From: casper@fwi.uva.nl (Casper H.S. Dik) Newsgroups: comp.unix.solaris,comp.unix.bsd.misc Subject: Re: Solaris 2.6 Supersedes: <cancel.casper.329ae8f2@mail.fwi.uva.nl> Date: 26 Nov 1996 13:56:19 +0100 Organization: Sun Microsystems, Netherlands Lines: 143 Distribution: inet Message-ID: <casper.329ae8f2@mail.fwi.uva.nl> References: <32986299.AC7@mail.esrin.esa.it> <57djlg$bks@agate.berkeley.edu> <57dkbq$bsr@panix2.panix.com> <casper.329abb76@mail.fwi.uva.nl> <57ej3a$7ij@panix2.panix.com> NNTP-Posting-Host: mail.fwi.uva.nl Xref: euryale.cc.adfa.oz.au comp.unix.solaris:90453 comp.unix.bsd.misc:1599 tls@panix.com (Thor Lancelot Simon) writes: [ I *really* hate it when people send me copies of replies thru email; invariably this I end up replying twice ] >>tls@panix.com (Thor Lancelot Simon) writes: >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. What about old .o files? Old dynamic libraries? Old archive libraries? How do you compile using those? You *can't* do it in the way you describe. You need new external symbols. I know that free-unixes don't really care that much about binary compatibility (you should only run applications you ahve source for, right?) >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. No, but code that uses "long" to calculate with off_t's will need to be fixed; it won't compile or just gives a warning and an erronous computation. You can claim that such code has a bug, but you also have the C-standard claiming that lng is the largest integral type. >>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. The dynamic libraries will need to retain the old "open" entry point for use by old applications. >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. :-) I think you guys are being casual about supporting preexisting software in binary form; apart from a lot of broken code being sold that still must work after we go to large files, there's also a lot of the following around: - vendors shipping archive/dynamic libraries for users to link against (All major DB vendors, for one) - libraries created/maintained locally You can't solve that without keeping the old symbols and sizes available. You can say, well just bump the libc.so. revision number? Well, it wouldn't work; you'd get your users into a complex mess requiring them to link either 32bit file only objects or 64bit file only objects. Since "open/lseek/stat" etc are already taken the "open64" etc calls are used (invisibly) as entry points for 64bit compiled objects. >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. I think that, as usual, free Unixes ignore an important part of what binary compatibility consists of *for commercial unixes*. The market is different, the requirements are different. Tell me, can you take 4.3 BSD .o files and link them to a 4.4 BSD program> >>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. No, I'm suggesting that 32bit off_t programs may corrupt >32bit files because of truncation that happens when seek pointers are obtained and later used. There's still the unsolvable problem of large fds inherited by non largefile savvy programs. >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. Sure, but we'd have gone to some traumatic source transformations before. I don't believe we can sell "sure you must rebuild all your .o files and libraries" to customers upgrading to 2.6. >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*? That's really only needed for the components of the ssytem that need to distinguish, such as the kernel and the libraries. It's not for use in programs. It's not something application developers have to go through (and again, and again, etc) >*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. Nothing you said has convinced me one bit that it is possible to redefine open() and get the backward compatibility exepected of a commercial OS vendor. There's one simple option to recompile your code (if it doesn't mixup off_t's and longs and if it doesn't define it's own types/ prototypes) to get largefiles. I don't see a way to do it differently, given the constraints commercial OS vendors operate under. Casper -- Casper Dik - Sun Microsystems - via my guest account at the University of Amsterdam. My work e-mail address is: Casper.Dik@Holland.Sun.COM Statements on Sun products included here are not gospel and may be fiction rather than truth.