Message-ID: <4D06446E.6020104@redhat.com>
Date: Mon, 13 Dec 2010 09:06:06 -0700
From: Eric Blake <eblake@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7
MIME-Version: 1.0
To: Jay K <jay.krell@cornell.edu>
CC: cygwin@cygwin.com, corinna-cygwin@cygwin.com
Subject: Re: upper limit to df reported available size?
References: <1292030585.3028.ezmlm@cygwin.com> <COL101-W496C2AAD8F993F427FAFDDE6100@phx.gbl>
In-Reply-To: <COL101-W496C2AAD8F993F427FAFDDE6100@phx.gbl>
OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig16F443392593333AA1772D35"
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

--------------enig16F443392593333AA1772D35
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 12/10/2010 06:51 PM, Jay K wrote:
>=20
>  >  I guess what we really need
>  > is to redefine fsblkcnt_t to become a 64 bit type. Oh well, this
>  > requires another backward compatibility hack, just like back when we
>  > switched to 64 bit off_t (Cygwin 1.5). Let's do it at the same time as
>  > we change sigset_t and time_t to 64-bits(with knock-on effects to
>  > struct stat, among others). In other words,all good changes, but certa=
inly
>  > something that will take a lot ofplanning to pull off in one go.
>=20=20
>=20=20
> Can you fix the jmp_buf size then too maybe?
> It is blown up by a factor of 4.
> http://sourceware.org/ml/cygwin/2009-01/msg00863.html
>=20=20
> I realize it has less/no value to fixing.
> But I'm not sure how changing the others won't require *everything*
> (just about) to be recompiled anyway. Maybe you rename functions somehow?

It's a matter of linker magic.  For example, when stat() was changed
from 32-bit to 64-bit sizes, cygwin1.dll was set up with two entry
points, stat() and stat64(), but the dll export table only has one entry
point stat().  Old apps that were compiled when there was only a 32-bit
entry point continue to call stat(), but now that the dll export table
exposes only stat pointing to stat64(), all recompilations automatically
pick up the new stat size.  There's also some #defines required in the
headers to allow compilation of cygwin itself to support both function
calls, while only exposing the new sizes to newly compiled apps.

When (if? since someone has to do it) fsblkcnt_t is resized, you won't
be required to recompile, but you won't benefit from the fixed sizes
unless you recompile.  And coreutils (including df) would obviously be
one of the first apps to recompile with the new sizes, as a good
testcase that we got the resizing done correctly.

--=20
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


--------------enig16F443392593333AA1772D35
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJNBkRuAAoJEKeha0olJ0NqxwkH/RRHf7tBWBx4QubdyueTt5UP
O81lnjh0cbGcpNyemdh0QUunud+VxKEj+BlFuJlQizeEtyb5wQrapYs9T3kjmZbt
AFoUTaRJrFOY6AwWxgm7ery/55U4fpSfD/6HTQ0lFcXHctXsWHTvatVyXA0XBlPL
BRXSNULixduVL41FBMAjSNZByAukabXIwR/LV90/NJbYlzRIU+nnz8TREKbaXRP3
zSwJMhvceFvq3ti7V6a5kYtNQWNiHLED3uRAVy6HWV9ECHxUUyej+cOFhTuumNiF
uFTPIVISEPBRi4fLslK2+a1HMUKQjW2geE+JEo79iEg86dMARZycxJNaLBtf23k=
=XHVY
-----END PGP SIGNATURE-----

--------------enig16F443392593333AA1772D35--