Will Newton <will.newton@xxxxxxxxx> 写于 2009-03-25 20:01:02: > 2009/3/25 <liqin.chen@xxxxxxxxxxxxx>: > >> > >> 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 <will.newton@xxxxxxxxx> 写于 2009-03-24 19:00:05: > > > >> On Tue, Mar 24, 2009 at 3:46 AM, <liqin@xxxxxxxxxxxxxxx> 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 <liqin.chen@xxxxxxxxxxxxx, > >> > liqin@xxxxxxxxxxxxxxx> > > ?韬{.n?????%??檩??w?{.n???{饼??Ф?塄}?财??j:+v?? ? ???2??璀??摺?囤??z夸z罐?+?????w棹f
