64 bit support

[Jeremy Allison]

On Tue, Sep 26, 2000 at 04:12:56PM +1000, Andrew Tridgell wrote:
> I've been playing with 64 bit support on Linux i386.  As usual the
> problems are primarily with locking, the glibc headers and code are
> really bad, making it just about impossible to make 64 bit off_t work.
> 
> Anyway, I have got it to work with some gross hacks involving
> bypassing the C library for fcntl() and I'll be putting that in as a
> compile time option for those people who really need 64 bit support in
> Samba on Intel Linux.
> 
> Meanwhile, I propose that we drop the explicit calls to open64() and
> friends in Samba and instead use the LFS way of doing things where
> compiler flags are used to select a 64 bit interface by default. This
> seems to be widely supported now and makes the application code much
> cleaner.
> 
> Jeremy, you've dealt with this issue before, what do you think of
> removing the explicit 64 bit calls and instead use something like the
> AC_SYS_LARGEFILE autoconf macro (or something equivalent) to set the
> right compiler flags to get a 64 bit default interface. 

I hate doing this just for one broken platform, even if it is
our most popular one.

I'd rather leave the explicit largefile open64 style calls in
place in the code for non-broken systems that need them and have
an autoconf flag to turn them off that we can use on broken systems like
RedHat 7.0.

We can detect broken largefile calls and try and turn them
off - this would mean less disruption in the code.

We already wrap all the xxx64 calls behind sys_xxxx wrappers
so it won't mean any disruption in the core code - just a set
of ifdefs in the lib/system.c wrapper code.

> We would need some more extensive autoconf tests of the 64 bit
> interface (particularly with locking) but the advantage would be
> simpler and more maintainable code.


That's why I'm loath to change this code so close to a 2.2.0
release -  this code was tested carefully on IRIX, HPUX and
Solaris and is correct w.r.t several versions of these platforms.

Making a quick hack just because RedHat 7.0 shipped as completely
broken stands to break all the carefully tested code on all these
other platforms - if we were to do this we'd have to get all the
vendors to re-test on their platforms - this seems a little unfair
for a linux bug.

> RedHat 7.0 (glibc 2.1.95) and a 2.4.0test kernel then you get full
> support for 64 bit files except the locking is _completely_ broken.
> The effect is that the l_len parameter in struct flock gets seen by
> the kernel as 0 for all locks (it gets interpreted as a struct flock
> whereas glibc is giving it a struct flock64), which means all
> locks/unlocks apply from lock start to EOF. This completely breaks tdb
> and can easily cause data corruption with Samba. This is going to make
> for some interesting bug reports in some packages I expect.

Oh god - how did they ship this..........

Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------