On 5 December 2012 21:17, Markos Chandras <[email protected]> wrote: > On 5 December 2012 14:26, Vineet Gupta <[email protected]> wrote: >> On Wednesday 05 December 2012 07:37 PM, Markos Chandras wrote: >>> On 4 December 2012 12:46, Vineet Gupta <[email protected]> wrote: >>>> Also AFAIKR the last time we discussed, we'd agreed to try and remove >>>> any 64 to 32 translation layer. So my no-legacy-syscalls uClibc 0.9.30.3 >>>> (still work in progress) doesn't have a kernel_stat64 struct at all. >>>> I'll get back to you with my tentative patches in this regard. >>> >>> Hi Vineet, >>> >>> There are indeed many ways to solve this problem. What I have at this >>> point is the following layout >>> >>> /libc/sysdeps/linux/common-no-legacy/bits/statfs.h >>> >>> which includes a statfs and a statfs64 structure where the statfs >>> structure matches the layout of statfs64 but with 32-bit members and >>> padding. >>> >>> Similarly, I have >>> >>> /libc/sysdeps/linux/common-no-legacy/bits/stat.h >>> >>> again, this file includes a stat structure and a sta64 structure where >>> the stat structure matches the layout of stat64 but with 32-bit >>> members and >>> padding. >>> >>> Finally, there is the kernel_stat{64} problem. Right now, every >>> architecture defines its own kernel_stat{64} structures. However, new >>> architectures share the same stat structure >>> (include/uapi/asm-generic/stat.h). Moreover, kernel_stat and/or >>> kernel_stat64 are used internally in uClibc so I created a separate >>> file in >>> >>> libc/sysdeps/linux/common-no-legacy/bits/kernel_stat.h which just >>> includes <sys/stat.h> and does the following >>> >>> #define kernel_stat stat >>> #define kernel_stat64 stat64 >>> >>> Personally, I see no reason to redefine kernel_stat{64} structure with >>> a layout similar to stat/stat64. >>> >>> With these changes, no 32->64 translation is required. >>> >>> Any thoughts? >>> >> >> Perfect ! My implementation is almost similar - except that we don't >> need kernel_stat at all. I added a new config option which switches >> between your old itemized copy code and my no translation code. But if >> you are ready to forgoe that, then we don't need the addtional #ifdef >> mess :-) >> >> At any rate just to compare notes, I'll push my changes to my github >> branch first thing tomorrow and drop you a note. This will be based on >> your v2 0.9.33.2 (untested since I don't have a 0.9.33 for ARC yet). >> > > Hi Vineet, > > I noticed that my current branch does not compile for non-LFS > configurations. I will > test the non-LFS fixes locally and push them to github once I am done. > I expect to have > a "stable" branch tomorrow afternoon if that is ok. I will also push > my "generic stat/statfs" > patches on top of that for reference. > > -- > Regards, > Markos
Hi Vineet, I've updated the 0.9.33-syscalls-for-upstream branch with a couple of fixes from the v2 review https://github.com/hwoarang/uClibc I also created a "new-interfaces" branch with 3 additional patches deriving from the stat/statfs discussion https://github.com/hwoarang/uClibc/tree/new-interfaces Feedback is welcome -- Regards, Markos _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
