On 28 November 2012 10:58, Vineet Gupta <[email protected]> wrote:
> Precisely - now we are all on same page. So collecting all the ideas so
> far for conclusion:
>
> (3) Have stat/stat64 with same overall layout but stat will internally
> have 32 bit items (with appropriate padding) - allowing both structs to
> be used in the 64bit syscall interface. This needs no interworking crap
> except for some overflow checks (by testing high word).
I am currently doing that. 32-bit members and 32-bit padding for the
new struct statfs/stat. I am thinking we may have problems with
endianness? For example in little endian arches the padding should
come first whereas for big endian the pudding should come
second or something like that. We can go away with using 64-bit member
but this might break in some cases where the userland application does
not use typeof() to get the type of the struct member, but assumes
it's 32-bit or something.
>
> So in theory both #2 and #3 are acceptable solutions. I'd vote for #3.
>
> Comments !
>
> That should work. I will send a new
>> patch when I have something working.
>>
>>
>
> To make this plug-n-play for uClibc ports for future no-legacy-syscalls
> kernels, you probably would need to define a
> libc/sysdeps/linux/common-no-legacy/bits/{stat.h,xxx} and have that be
> selected based on !ARCH_HAS_DEPRECATED_SYSCALLS.
That seems fair yes. It's better to have a common place for these
arches instead of having each one of them
carrying their own structures (which will be pretty much identical)
>
> Markos, I'm extremely sorry if I/we are making your life miserable - but
> things touching the ABI are only done once so we better flush out any
> issues (including performance) before casting it in stone.
No worries. We are all on the same side here. It is a great learning
experience after all ;-)
--
Regards,
Markos
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
