>>>>> Ralf Baechle writes:
Ralf> On Sun, Jun 25, 2000 at 12:12:23PM +0200, Andreas Jaeger wrote:
>> this change is wrong (as also pointed out by Maciej). You removed the
>> following fields from struct stat64:
>>
>> char st_fstype[16]; /* Filesystem type name */
>> long st_pad4[8];
>> /* Linux specific fields */
>> unsigned int st_flags;
>> unsigned int st_gen;
>>
>> But if we compile user level programs with -D_FILE_OFFSET_BITS=64,
>> struct stat is renamed to struct stat64 - making st_fstype, st_flags
>> and st_gen mandatory for struct stat64.
>>
>> Could you please either add st_fstype, st_flags and st_gen to struct
>> stat64 - or remove them from both structures?
Ralf> Do you know of any users for those fields? I don't and we don't even
Ralf> properly initialize them, so I'd prefer to remove them - before some
Ralf> autoconf scripts detects and and uses them. My prefered solution would
Ralf> be to remove those fields, too.
Maciej commented in a separate mail on this as:
Maciej> Hmm, st_fstype is set in arch/mips/kernel/sysirix.c and
Maciej> arch/sparc64/solaris/fs.c. I'm not sure what it might be useful for,
Maciej> though. Maybe some broken Irix or Solaris programs refuse to work under
Maciej> emulation when there is no st_fstype set to an appropriate string. OK,
Maciej> both the i386 ABI and the MIPS one (I don't have any other ABIs) define
it
Maciej> so better leave it intact.
Maciej>
Maciej> There is no single reference in the 2.4.0-test1 kernel for either
Maciej> st_flags or st_gen beside headers (I suppose they should be removed to
Maciej> preserve memory). Therefore I vote for removal or at least renaming to
Maciej> something like __unused?. Why are they in glibc 2.1.90 anyway,
especially
Maciej> as they are not defined in glibc 2.1.3? The comment about being
Maciej> Linux-specific is confusing, too.
I agree with him - we can remove st_flags and st_gen without
problems. We need to check st_fstype. In all cases should the size
of struct stat not change (struct stat64 might shrink, but not struct
stat).
Andreas
--
Andreas Jaeger
SuSE Labs aj@xxxxxxx
private aj@xxxxxxxxxxxxxx
|