*BSD News Article 83608


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