>
> To allow people to more easily review your patches it is recommended
> to spit them up into smaller pieces and submit them to the mailing
> list.
According to the "The linux-kernel mailing list FAQ" and
"Documentation/SubmittingPatches",
E-mail size exceeds 40 kB, "it is preferred that you store
your patch on an Internet-accessibleserver, and provide
instead a URL (link) pointing to your patch."
linux/score patch size over 400 kB, so we only provide
the URL (link) in mail.
But if other person or Linus also think we should spit them up
into smaller pieces, we will do it.
>
> Your port looks relatively clean but it looks like it is borrowing
> heavily from the mips port and you may have a few leftovers from that
> e.g.:
>
Yes, we use linux/mips as reference for linux/score platform.
In order to make the patch clear, we used more C code instead of
assembler code. After patch merge to the mainline,
we will provide optimized assembler code one by one.
> - mentions of o32 (unless S+CORE has an o32 ABI?)
> - does SCORE+ have ll/sc instructions or is that another leftover from
MIPS?
No, I had removed these leftover code.
> - compatibility syscalls, sys_ipc, old-style signal handling. Are
> these really needed for a new arch?
Because we use glibc-2.3.6 as base library, LTP and many applications
are all running on it. so we leave many old syscall in score code,
once we are sure it's not necessary, we will remove these syscall.
> - does your port support SMP?
No, but we consider todo it next step.
We have updated the patch use the same URL(link)
http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
if other person think it should be splited into smaller pieces,
please let me know.
Thanks Will Newton
--
liqin
Will Newton <[email protected]> д?? 2009-03-24 19:00:05:
> On Tue, Mar 24, 2009 at 3:46 AM, <[email protected]> wrote:
> > Hello, Linus and folks,
> >
> > We have ported Linux to the S+CORE processor, which is a 32-bit RISC
> > embedded
> > microprocessor of Sunplus Core Technology.
> >
> > SPG29X, SPG300(score core) processor have been used in game products.
> > and score toolchain have commit to gnu in 2006. We have a team to
maintain
> > score code for linux kernel.
> >
> > We would like to release a patch for kernel 2.6.29-rc8.
> > This patch include score header files, arch files and serial driver
for
> > spct6600(score core) platform.
> >
> > For the other driver patches, I'll send them one by one in
> > small size latter. Thanks!
> >
> > Would you merge them to the stock kernel?
> >
> > Patch information is slightly bigger, so I placed it on our SunplusCT
web
> > site.
> >
http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
> >
> > Signed off by: Chen Liqin <[email protected],
> > [email protected]>
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
2009/3/25 <[email protected]>:
>>
>> To allow people to more easily review your patches it is recommended
>> to spit them up into smaller pieces and submit them to the mailing
>> list.
>
> According to the "The linux-kernel mailing list FAQ" and
> "Documentation/SubmittingPatches",
> E-mail size exceeds 40 kB, "it is preferred that you store
> your patch on an Internet-accessibleserver, and provide
> instead a URL (link) pointing to your patch."
> linux/score patch size over 400 kB, so we only provide
> the URL (link) in mail.
Yes, that's true. However if you split that up into 10-20 separate
emails then it's quite manageable. The advantage of posting to the
list is that many more people will review your code.
You could also cc the linux-arch mailing list.
> But if other person or Linus also think we should spit them up
> into smaller pieces, we will do it.
>
>>
>> Your port looks relatively clean but it looks like it is borrowing
>> heavily from the mips port and you may have a few leftovers from that
>> e.g.:
>>
>
> Yes, we use linux/mips as reference for linux/score platform.
> In order to make the patch clear, we used more C code instead of
> assembler code. After patch merge to the mainline,
> we will provide optimized assembler code one by one.
>
>> - mentions of o32 (unless S+CORE has an o32 ABI?)
>> - does SCORE+ have ll/sc instructions or is that another leftover from
> MIPS?
>
> No, I had removed these leftover code.
>
>> - compatibility syscalls, sys_ipc, old-style signal handling. Are
>> these really needed for a new arch?
>
> Because we use glibc-2.3.6 as base library, LTP and many applications
> are all running on it. so we leave many old syscall in score code,
> once we are sure it's not necessary, we will remove these syscall.
Once code is merged into mainline it becomes a lot harder to justify
making changes that break backwards compatibility such as removing
system calls. It's easier in the long term to make sure your system
call interface is cleaned up now rather than later.
Have you come across Arnd Bergmann's work on creating a generic arch
for porting?
http://lwn.net/Articles/307713/
It's a good reference to check which system calls are considered
current and which headers are generic in new ports etc.
>> - does your port support SMP?
>
> No, but we consider todo it next step.
>
> We have updated the patch use the same URL(link)
> http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
> if other person think it should be splited into smaller pieces,
> please let me know.
>
> Thanks Will Newton
> --
> liqin
>
> Will Newton <[email protected]> д?? 2009-03-24 19:00:05:
>
>> On Tue, Mar 24, 2009 at 3:46 AM, <[email protected]> wrote:
>> > Hello, Linus and folks,
>> >
>> > We have ported Linux to the S+CORE processor, which is a 32-bit RISC
>> > embedded
>> > microprocessor of Sunplus Core Technology.
>> >
>> > SPG29X, SPG300(score core) processor have been used in game products.
>> > and score toolchain have commit to gnu in 2006. We have a team to
> maintain
>> > score code for linux kernel.
>> >
>> > We would like to release a patch for kernel 2.6.29-rc8.
>> > This patch include score header files, arch files and serial driver
> for
>> > spct6600(score core) platform.
>> >
>> > For the other driver patches, I'll send them one by one in
>> > small size latter. Thanks!
>> >
>> > Would you merge them to the stock kernel?
>> >
>> > Patch information is slightly bigger, so I placed it on our SunplusCT
> web
>> > site.
>> >
> http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
>> >
>> > Signed off by: Chen Liqin <[email protected],
>> > [email protected]>
>
Will Newton <[email protected]> д?? 2009-03-25 20:01:02:
> 2009/3/25 <[email protected]>:
> >>
> >> To allow people to more easily review your patches it is recommended
> >> to spit them up into smaller pieces and submit them to the mailing
> >> list.
> >
> > According to the "The linux-kernel mailing list FAQ" and
> > "Documentation/SubmittingPatches",
> > E-mail size exceeds 40 kB, "it is preferred that you store
> > your patch on an Internet-accessibleserver, and provide
> > instead a URL (link) pointing to your patch."
> > linux/score patch size over 400 kB, so we only provide
> > the URL (link) in mail.
>
> Yes, that's true. However if you split that up into 10-20 separate
> emails then it's quite manageable. The advantage of posting to the
> list is that many more people will review your code.
>
> You could also cc the linux-arch mailing list.
>
> > But if other person or Linus also think we should spit them up
> > into smaller pieces, we will do it.
> >
> >>
> >> Your port looks relatively clean but it looks like it is borrowing
> >> heavily from the mips port and you may have a few leftovers from that
> >> e.g.:
> >>
> >
> > Yes, we use linux/mips as reference for linux/score platform.
> > In order to make the patch clear, we used more C code instead of
> > assembler code. After patch merge to the mainline,
> > we will provide optimized assembler code one by one.
> >
> >> - mentions of o32 (unless S+CORE has an o32 ABI?)
> >> - does SCORE+ have ll/sc instructions or is that another leftover
from
> > MIPS?
> >
> > No, I had removed these leftover code.
> >
> >> - compatibility syscalls, sys_ipc, old-style signal handling. Are
> >> these really needed for a new arch?
> >
> > Because we use glibc-2.3.6 as base library, LTP and many applications
> > are all running on it. so we leave many old syscall in score code,
> > once we are sure it's not necessary, we will remove these syscall.
>
> Once code is merged into mainline it becomes a lot harder to justify
> making changes that break backwards compatibility such as removing
> system calls. It's easier in the long term to make sure your system
> call interface is cleaned up now rather than later.
>
> Have you come across Arnd Bergmann's work on creating a generic arch
> for porting?
>
> http://lwn.net/Articles/307713/
>
> It's a good reference to check which system calls are considered
> current and which headers are generic in new ports etc.
>
Had removed compatibility syscalls from the code.
last patch still placed at
http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
> >> - does your port support SMP?
> >
> > No, but we consider todo it next step.
> >
> > We have updated the patch use the same URL(link)
> >
http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
> > if other person think it should be splited into smaller pieces,
> > please let me know.
> >
> > Thanks Will Newton
> > --
> > liqin
> >
> > Will Newton <[email protected]> д?? 2009-03-24 19:00:05:
> >
> >> On Tue, Mar 24, 2009 at 3:46 AM, <[email protected]> wrote:
> >> > Hello, Linus and folks,
> >> >
> >> > We have ported Linux to the S+CORE processor, which is a 32-bit
RISC
> >> > embedded
> >> > microprocessor of Sunplus Core Technology.
> >> >
> >> > SPG29X, SPG300(score core) processor have been used in game
products.
> >> > and score toolchain have commit to gnu in 2006. We have a team to
> > maintain
> >> > score code for linux kernel.
> >> >
> >> > We would like to release a patch for kernel 2.6.29-rc8.
> >> > This patch include score header files, arch files and serial driver
> > for
> >> > spct6600(score core) platform.
> >> >
> >> > For the other driver patches, I'll send them one by one in
> >> > small size latter. Thanks!
> >> >
> >> > Would you merge them to the stock kernel?
> >> >
> >> > Patch information is slightly bigger, so I placed it on our
SunplusCT
> > web
> >> > site.
> >> >
> >
http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
> >> >
> >> > Signed off by: Chen Liqin <[email protected],
> >> > [email protected]>
> >
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Fri, 27 Mar 2009, [email protected] wrote:
> > >> > We would like to release a patch for kernel 2.6.29-rc8.
> > >> > This patch include score header files, arch files and serial driver
> > > for
> > >> > spct6600(score core) platform.
> > >> >
> > >> > For the other driver patches, I'll send them one by one in
> > >> > small size latter. Thanks!
> > >> >
> > >> > Would you merge them to the stock kernel?
> > >> >
> > >> > Patch information is slightly bigger, so I placed it on our
> SunplusCT
> > > web
> > >> > site.
> > >> >
> > >
> http://www.sunplusct.com/images/linux-score-patch/linux-score-20090324.patch
Please split the patches further into logical and reviewable
pieces. Also each patch needs a patch description which will be the
change log in the git repository and your Signed-off-by line. Also
each patch needs a unique and useful subject line in the mail.
Download references for such patches are useless.
See Documentation/SubmittingPatches
Thanks,
tglx