Date: Mon, 30 Oct 2000 17:03:12 -0800
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
I could definitely agree with this. time_t needs to go 64 bits too,
although we have a little more time for that...
Sorry, we don't have more time. NFSv3 already supports time values
that cannot be sto
> Date: Tue, 31 Oct 2000 03:00:43 +0200
> From: Matti Aarnio <[EMAIL PROTECTED]>
> The more I am following this disaster called ABI evolution, the more
> I am convinced that IBM did indeed do something right at the switch
> from AIX 3.x to AIX 4.x -- ALL SCALAR INTEGERS AT AIX 4.x A
On Tue, Oct 31, 2000 at 03:00:43AM +0200, Matti Aarnio wrote:
> For some things even 64 bits are not enough
I tend to think that time_t is an example.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Matti Aarnio <[EMAIL PROTECTED]> writes:
> We had this 64-bits-or-not discussion with Ulrich back when 2.1 was
> imminent, and he was utterly convinced that it is good to save space
> at various LFS related structure fields.
The LFS data structures are fine. Inform yourself before compla
On Mon, 30 Oct 2000, H. Peter Anvin wrote:
> UTF-16 is utter crap, anyway. UTF-8 or UCS-4/UTF-32 are the only sane
> encodings of Unicode (one multibyte, one wide. UTF-16 combines the
> advantages of neither and the disadvantages of both.)
No arguments. I would prefer UTF-8 - much easier to
Alexander Viro wrote:
>
> On Tue, 31 Oct 2000, Matti Aarnio wrote:
>
> > Something along the lines of: As we no longer have access control
> > in form of having magic UIDs, e.g. zero vs. non-zero, we could as well
> > begin to use UTF-16 UNICODE 3.0 encoded strings for UID referral in
> >
On Tue, 31 Oct 2000, Matti Aarnio wrote:
> Something along the lines of: As we no longer have access control
> in form of having magic UIDs, e.g. zero vs. non-zero, we could as well
> begin to use UTF-16 UNICODE 3.0 encoded strings for UID referral in
> fixed size arrays giving us inst
Matti Aarnio wrote:
>
> We had this 64-bits-or-not discussion with Ulrich back when 2.1 was
> imminent, and he was utterly convinced that it is good to save space
> at various LFS related structure fields. Now that is coming to haunt
> us... (I distinctly recall of him mentioning of re
On Mon, Oct 30, 2000 at 02:39:27PM -0800, Ulrich Drepper wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
> > Fair enough. However, the question still remains if we should make it
> > the default and make the old heterogenous API the explicit option.
>
> Sure, this can be done. When the
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Fair enough. However, the question still remains if we should make it
> the default and make the old heterogenous API the explicit option.
Sure, this can be done. When the time comes. Certainly not in glibc
2.2. This always was the plan and sinc
Mark Kettenis wrote:
>
>Date: Mon, 30 Oct 2000 14:08:44 -0800
>From: "H. Peter Anvin" <[EMAIL PROTECTED]>
>
>If so, we'd be better off completely deprecating the old calls and make
>the LFS calls the default calls (and off_t == off64_t, ino_t == ino64_t,
>etc.)
>
> Except th
Date: Mon, 30 Oct 2000 14:08:44 -0800
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
If so, we'd be better off completely deprecating the old calls and make
the LFS calls the default calls (and off_t == off64_t, ino_t == ino64_t,
etc.)
Except that the LFS calls aren't completely imple
Ulrich Drepper wrote:
>
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
> > Sorry for being picky, but LFS, specifically, means using an heterogenous
> > API using seek64() instead of lseek() and so on and so forth.
>
> Wrong. LFS also includes -D_FILE_OFFSET_BITS=64 which transparently
> rep
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Sorry for being picky, but LFS, specifically, means using an heterogenous
> API using seek64() instead of lseek() and so on and so forth.
Wrong. LFS also includes -D_FILE_OFFSET_BITS=64 which transparently
replaces the non-LFS types and functions.
Ben LaHaise wrote:
>
> On Mon, 30 Oct 2000, H. Peter Anvin wrote:
>
> > 6. Either way, existing binaries cannot handle stat() on 64-bit inode
> > filesystems.
> >
> > Ideas, anyone?
>
> Don't use filesystems that require 64 bit inode numbers until all
> applications are using LFS. Personally I
On Mon, 30 Oct 2000, H. Peter Anvin wrote:
> 6. Either way, existing binaries cannot handle stat() on 64-bit inode
> filesystems.
>
> Ideas, anyone?
Don't use filesystems that require 64 bit inode numbers until all
applications are using LFS. Personally I'd rather LFS not be an option
anymore
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> 6. Either way, existing binaries cannot handle stat() on 64-bit inode
> filesystems.
I have Cc:'d this to the linux-fs-devel list; hopefully we can get some
communication going.
Mark Kettenis wrote:
>
>I believe I wrote this back as well: this will affect *ALL* applications,
>even those that don't need large file support. This change really needs
>to happen, or any
18 matches
Mail list logo
