>From 9741f7928ef35416e49f329a64e623a109de5c2d Mon Sep 17 00:00:00 2001
From: Chen Liqin <[email protected]>
Date: Mon, 26 Oct 2009 10:50:50 +0800
Subject: [PATCH] asm-generic: Fix typo in asm-generic/unistd.h.
Fixed __NR_ftruncate and __NR_ftruncate64 define in asm-generic/unistd.h.
Signed-off-by: Chen Liqin <[email protected]>
---
include/asm-generic/unistd.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/unistd.h b/include/asm-generic/unistd.h
index d76b66a..2869650 100644
--- a/include/asm-generic/unistd.h
+++ b/include/asm-generic/unistd.h
@@ -802,7 +802,7 @@ __SYSCALL(__NR_fork, sys_ni_syscall)
#define __NR_statfs __NR3264_statfs
#define __NR_fstatfs __NR3264_fstatfs
#define __NR_truncate __NR3264_truncate
-#define __NR_ftruncate __NR3264_truncate
+#define __NR_ftruncate __NR3264_ftruncate
#define __NR_lseek __NR3264_lseek
#define __NR_sendfile __NR3264_sendfile
#define __NR_newfstatat __NR3264_fstatat
@@ -818,7 +818,7 @@ __SYSCALL(__NR_fork, sys_ni_syscall)
#define __NR_statfs64 __NR3264_statfs
#define __NR_fstatfs64 __NR3264_fstatfs
#define __NR_truncate64 __NR3264_truncate
-#define __NR_ftruncate64 __NR3264_truncate
+#define __NR_ftruncate64 __NR3264_ftruncate
#define __NR_llseek __NR3264_lseek
#define __NR_sendfile64 __NR3264_sendfile
#define __NR_fstatat64 __NR3264_fstatat
--
1.6.2
On Monday 26 October 2009, Chen Liqin wrote:
> >From 9741f7928ef35416e49f329a64e623a109de5c2d Mon Sep 17 00:00:00 2001
> From: Chen Liqin <[email protected]>
> Date: Mon, 26 Oct 2009 10:50:50 +0800
> Subject: [PATCH] asm-generic: Fix typo in asm-generic/unistd.h.
>
> Fixed __NR_ftruncate and __NR_ftruncate64 define in asm-generic/unistd.h.
>
> Signed-off-by: Chen Liqin <[email protected]>
Applied, thanks!
I assume that means you are progressing with getting all bugs fixed that
were introduced in the conversion to the asm-generic headers. Do you
have a full glibc running again, and passing LTP?
Arnd <><
Arnd Bergmann <[email protected]> д?? 2009-11-02 16:39:14:
> I assume that means you are progressing with getting all bugs fixed that
> were introduced in the conversion to the asm-generic headers. Do you
> have a full glibc running again, and passing LTP?
Yes Arnd,
asm-generic headers could run on linux/score platform well,
we upgradge libc to glibc-2.5 and passed LTP testsuites.
we will gradually release score-linux toolchain on our website.
Best Regards
Liqin
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Tuesday 03 November 2009, [email protected] wrote:
> asm-generic headers could run on linux/score platform well,
> we upgradge libc to glibc-2.5 and passed LTP testsuites.
> we will gradually release score-linux toolchain on our website
Ah, good to hear!
Is there any reason to use glibc-2.5 though? The current release
is 2.10.1, and the version you used is over three years old.
Do you have plans to merge your port into eglibc when it's done?
Arnd <><
Arnd Bergmann <[email protected]> д?? 2009-11-03 16:52:17:
> Is there any reason to use glibc-2.5 though? The current release
> is 2.10.1, and the version you used is over three years old.
We found many stable toolchain use glibc-2.5. so we select it.
In fact, what we think first is to could used it in product??
Even linux kernel, in company we still use kernel-2.6.27 version.
> Do you have plans to merge your port into eglibc when it's done?
>
We have not this plan now.
Liqin
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Wednesday 04 November 2009, [email protected] wrote:
> Arnd Bergmann <[email protected]> д?? 2009-11-03 16:52:17:
>
> > Is there any reason to use glibc-2.5 though? The current release
> > is 2.10.1, and the version you used is over three years old.
>
> We found many stable toolchain use glibc-2.5. so we select it.
> In fact, what we think first is to could used it in product??
It is unfortunately a common misunderstanding that older releases
that are currently used by others are more stable. The reason
you find glibc-2.5 in products today is that it was the current
version at the time when the development cycle for the product
was started.
In general, when you upgrade to a more recent version, the
best idea is to take the latest stable release, and stabilizing
on that for a given embedded product. By always using the latest
version, you can greatly reduce the amount of work needed for
each upgrade, and you get all improvements and bug fixes
automatically without having to backport them.
> Even linux kernel, in company we still use kernel-2.6.27 version.
Yes, that is good and expected, if that version has proven to be
stable for you.
Obviously you will have to do an update at some point and then
you can easily move to the latest kernel version since it is now
upstream.
I also expect that you have device driver code that is not yet
upstream. Getting that in should be a lot easier than the initial
architecture code and Greg KH can help you with his drivers/staging
infrastructure if you are interested.
> > Do you have plans to merge your port into eglibc when it's done?
>
> We have not this plan now.
I would recommend to look into this at some point in the future.
Unlike the main glibc project, eglibc[1] is specifically there for
supporting embedded architectures and already hosts ports for
other platforms that are not in glibc itself, while it closely
follows the main glibc development. Contributing there unfortunately
requires some paperwork for copyright assignment, but it's probably
worth it in the end.
You've done the right thing by merging your kernel code into the
official Linux tree, porting your glibc code to the lastest
snapshot and submitting it into eglibc is the next big step.
Arnd <><
--
[1] http://www.eglibc.org/
[email protected] д?? 2009-11-04 17:28:11:
> I would recommend to look into this at some point in the future.
> Unlike the main glibc project, eglibc[1] is specifically there for
> supporting embedded architectures and already hosts ports for
> other platforms that are not in glibc itself, while it closely
> follows the main glibc development. Contributing there unfortunately
> requires some paperwork for copyright assignment, but it's probably
> worth it in the end.
>
> You've done the right thing by merging your kernel code into the
> official Linux tree, porting your glibc code to the lastest
> snapshot and submitting it into eglibc is the next big step.
>
Hi Arnd??
Thank you for the above suggestions and comments,
We will evaluate your suggestions and continue upgrading.
to make linux/score platform work better.
Best Regards
Liqin
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?