[Xprint] Xserver large file aware?

[Adam Jackson]

On Tuesday 12 April 2005 17:45, Roland Mainz wrote:
> Alan Coopersmith wrote:
> > I don't think anyone's done any work in that area, since the X server
> > doesn't normally access files that have any need of being that large.
> > (A 2gb config file would be truly frightening.)
>
> A 2GB config file will hopefully something we will never see... =:-)
> ... but there are things like |mmap()| of device spaces or kernel/PCI
> space which may hit that issue (or output files such as spooler or log
> files (which may harm longrunning Xservers)).
> But again we are hitting a problem here: Recompiling the Xserver code
> with largefile support enabled will likely break the module ABI as there
> are AFAIK some 32bit-only I/O libc functions emulated by the ELF loader

This is not an ABI break in the sense you're thinking of.  You can't load a 
32-bit driver from a 64-bit server or vice versa.  (If you can, you shouldn't 
be able to, it's a horrible idea, and I will make sure it fails in the 
future.)

There are three cases:

- 32 bit object, no LFS.  This is where we are now on ILP32.
- 32 bit object, LFS.  Need to add 64-bit entrypoints for mmap and friends and
  add 64 bit size_t's for them.
- 64 bit object, implicit LFS.  This is where we are now for LP64.

> - and the datatypes for offsets are AFAIK 32bit and not 64bit

No, xf86size_t is a typedef for unsigned long and is used in place of off_t in 
all the function signatures where it matters.  A quick grep shows that we 
never encode xf86size_t in a struct or pass it over the wire, so this is 
handled entirely by new entrypoints.

Note that if you use separate typedefs for the smallfile and largefile 
size_t's, then you can load smallfile drivers on largefile servers.  The 
reverse won't work because the driver will explicitly require the new 
entrypoints and the smallfile server won't have them.  We only need to extend 
the ABI for ILP32, assuming we even care about LFS on ILP32; there's not 
enough context in the quoted text to know if this is really an issue.

> (yes, it 
> would be possible to add |*64()| versions of the 32bit functions to the
> libc emulation in the ELF loader but that does not cure the general
> problem (and ignores the existance of the dlloader completely)).

This really has nothing to do with the loader, it has to to with the libc 
wrapper.  Adding entrypoints to the libc wrapper for ILP32+LFS will work for 
all four loaders.

> The only ad-hoc solution here may be to recompile the Xserver as 64bit
> application and add the issue that "the Xserver core is not largefile
> aware" to the wishlist of things which should be fixed if the module ABI
> gets reworked (which will likely not happen until h*ll freezes... ;-().

Again, not an ABI break.  At most we would need an ABI extension for ILP32 
systems.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-arch/attachments/20050413/8980cb3a/attachment.pgp