Hi tglx, Arnd, Kyle, Sam and linus,
According to your comment last week, We had updated the linux/score code,
use arch blackfin code as reference.
because some reasons below, I have not fixed these problems you mentioned
1: bdflush is not a nop, remove it?
2: because module_arch_cleanup, makcine_halt, machine_power_off and
some other funcs are global,
so i have not move them into .h and not declare them as static
inline.
3:
> +#define __NR_exit (__NR_Linux + 1)
> +#define __NR_fork (__NR_Linux + 2)
> +#define __NR_read (__NR_Linux + 3)
> +#define __NR_write (__NR_Linux + 4)
> +#define __NR_open (__NR_Linux + 5)
> +#define __NR_close (__NR_Linux + 6)
> +#define __NR_waitpid (__NR_Linux + 7)
> +#define __NR_creat (__NR_Linux + 8)
> +#define __NR_link (__NR_Linux + 9)
> +#define __NR_unlink (__NR_Linux + 10)
> +#define __NR_execve (__NR_Linux + 11)
> +#define __NR_chdir (__NR_Linux + 12)
> +#define __NR_time (__NR_Linux + 13)
> +#define __NR_mknod (__NR_Linux + 14)
> +#define __NR_chmod (__NR_Linux + 15)
> +#define __NR_lchown (__NR_Linux + 16)
> +#define __NR_break (__NR_Linux + 17)
I still leave these syscalls there, bacause i think it clear to everybody
even linux have the new syscall replace them.
4: asm/atomic.h and asm/bitops.h generic version have not finished,
so I dont updated them.
5:
> +#define __ARCH_WANT_SYS_FADVISE64
> +#define __ARCH_OMIT_COMPAT_SYS_GETDENTS64
> +#define __ARCH_WANT_IPC_PARSE_VERSION
> +#define __ARCH_WANT_OLD_READDIR
> +#define __ARCH_WANT_SYS_ALARM
> +#define __ARCH_WANT_SYS_GETHOSTNAME
> +#define __ARCH_WANT_SYS_PAUSE
> +#define __ARCH_WANT_SYS_SGETMASK
> +#define __ARCH_WANT_SYS_UTIME
> +#define __ARCH_WANT_SYS_WAITPID
> +#define __ARCH_WANT_SYS_SOCKETCALL
> +#define __ARCH_WANT_SYS_GETPGRP
> +#define __ARCH_WANT_SYS_LLSEEK
> +#define __ARCH_WANT_SYS_NICE
> +#define __ARCH_WANT_SYS_OLD_GETRLIMIT
> +#define __ARCH_WANT_SYS_OLDUMOUNT
> +#define __ARCH_WANT_SYS_SIGPENDING
> +#define __ARCH_WANT_SYS_SIGPROCMASK
> +#define __ARCH_WANT_SYS_RT_SIGACTION
> +#define __ARCH_WANT_STAT64
> +#define __ARCH_WANT_SYS_TIME
Once the kernel code update, I will remove these code.
6: sys_sigaltstack should rename to sys_rt_sigaltstack?
7: use score-linux compile linux/score kernel still have some
warning,
but we think it not the problems in score head files.
8: score have big and little endian support, now we only use
little endian running linux.
score-linux toolchain could be download from
http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
linux/score lastest patch place at
http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
--
Best regards
Liqin
[email protected]
On Wed, 8 Apr 2009 15:18:30 +0800 [email protected] wrote:
>
This emailed patches are badly wordwrapped and
> http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
has no changelogs, no attributions and no Signed-off-by:'s.
That's not a problem right now as we can still review the code, but
these things will need to be sorted out soon, please.
Thanks Arnd, our MIS help me solve the download problem.
> Feel free to base you code on top of asm-generic.git#next, but tell me
> when you intend to do that so I can warn you of possibly rebases.
Last week, I had updated score code base on asm-generic.git#next.
and I will apply a account on kernel.org, But before I get the account,
can you let score code merge in asm-generic.git?
liqin
--
On Monday 08 June 2009, [email protected] wrote:
> Thanks Arnd, our MIS help me solve the download problem.
>
> > Feel free to base you code on top of asm-generic.git#next, but tell me
> > when you intend to do that so I can warn you of possibly rebases.
>
> Last week, I had updated score code base on asm-generic.git#next.
>
> and I will apply a account on kernel.org, But before I get the account,
> can you let score code merge in asm-generic.git?
I can take your patches and apply them to a new branch in my tree
if that helps. I hope that Linus can pull my tree early in the
merge window so your architecture port and the microblaze changes
based on it can also get in soon.
I guess for the new architecture, it makes sense to combine all
your patches into a single changeset in git, since they don't
make sense until you have the complete set, and your changeset
comments are rather boring so far anyway.
Can you write a few paragraphs of text about your architecture
for the initial changeset comment? I think it would be good
to permanently store some facts in there, e.g. in which ways
the architecture is different from others, where to get a
toolchain and what kinds of hardware exist for it.
I'll go through the patches once more and see if I find anything
that should still be changed before the code goes in, but
from a brief look, the code looks pretty good now.
Arnd <><
Thanks Arnd, tglx, Sam and all who pay attention to score code.
We will update score arch code to catch up the
linux/kernel code level. The next patches will
send out soon.
Best Regards
liqin
--
Arnd Bergmann <[email protected]> д?? 2009-06-10 00:37:28:
> On Monday 08 June 2009, [email protected] wrote:
> > Thanks Arnd, our MIS help me solve the download problem.
> >
> > > Feel free to base you code on top of asm-generic.git#next, but tell
me
> > > when you intend to do that so I can warn you of possibly rebases.
> >
> > Last week, I had updated score code base on asm-generic.git#next.
> >
> > and I will apply a account on kernel.org, But before I get the
account,
> > can you let score code merge in asm-generic.git?
>
> I can take your patches and apply them to a new branch in my tree
> if that helps. I hope that Linus can pull my tree early in the
> merge window so your architecture port and the microblaze changes
> based on it can also get in soon.
>
> I guess for the new architecture, it makes sense to combine all
> your patches into a single changeset in git, since they don't
> make sense until you have the complete set, and your changeset
> comments are rather boring so far anyway.
>
> Can you write a few paragraphs of text about your architecture
> for the initial changeset comment? I think it would be good
> to permanently store some facts in there, e.g. in which ways
> the architecture is different from others, where to get a
> toolchain and what kinds of hardware exist for it.
>
> I'll go through the patches once more and see if I find anything
> that should still be changed before the code goes in, but
> from a brief look, the code looks pretty good now.
>
> Arnd <><
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?