Thank you for your valuable information: it will let kernel waste mails less, and also can save my time resources. On 09/04/2013 04:59 AM, Guenter Roeck wrote: > On Tue, Sep 03, 2013 at 08:39:38PM +0100, Al Viro wrote: >> On Tue, Sep 03, 2013 at 11:52:17AM +0800, Chen Gang F T wrote: >> >>> extreme sample: let 'kernel code style' and 'gcc code style' in one file, that will make the code very ugly. >> >> gcc style will make any code very ugly, no matter what (if anything) else is >> in the same file... >> Hmm... for me, I don't check/judge the 'coding style' of different products, what I focus on is to follow the original product 'coding style'. e.g. Windows, gcc, Linux kernel, their 'coding styles' are quite different with each other. Originally I worked under Windows, I followed Windows coding style. Now I worked under Linux kernel, I follow Linux kernel coding style. I plan to make patch for gcc, I will follow gcc coding style. (hope this month I can, but I am not sure, I have no experience for gcc development). And excuse me, I will be silent during 2013-09-05 - 2013-09-20 (but can response mail). During these days, I will focus on gcc issues (wish can fix one), and also do some company's internal things. Thanks. >> [digs out the ports history table] >> x86: 0.01 [alive] >> i386: 0.01..2.6.24-rc1 [folded into x86] >> x86_64: 2.5.5-pre1..2.6.24-rc1 [folded into x86] >> x86: 2.6.24-rc1 [alive] >> alpha: 1.1.67 [alive] >> sparc: 1.1.77 [alive] >> sparc64: 2.1.19..2.6.28 [folded into sparc] >> mips: 1.1.82 [alive] >> mips64: 2.3.48-pre2..2.6.0-test2 [folded into mips] >> powerpc: 1.3.45 [alive] >> ppc: 1.3.45..2.6.26 [folded into powerpc] >> ppc64: 2.5.5..2.6.15-rc1 [folded into powerpc] >> powerpc: 2.6.15-rc1 [alive] >> m68k: 1.3.94 [alive] >> m68knommu: 2.5.46..2.6.38 [folded into m68k] >> arm: 2.1.80 [alive] >> arm26: 2.5.71..2.6.23-rc2 [gone] >> arm64: 3.7-rc1 [alive][might eventually fold] >> sh: 2.3.16 [alive] >> sh64: 2.6.8-rc1..2.6.24 [folded into sh, nearly dead there] >> ia64: 2.3.43-pre1 [alive] >> s390: 2.3.99pre8 [alive] >> s390x: 2.5.0..2.5.67 [folded into s390] >> parisc: 2.4.0-test12 [alive] >> cris: 2.5.0 [alive] >> um: 2.5.35 [alive] >> v850: 2.5.46..2.6.26 [gone] >> h8300: 2.5.68 [moderately responsive] >> m32r: 2.6.9-rc3 [alive] >> frv: 2.6.11-rc1 [alive] >> xtensa: 2.6.13-rc1 [alive] >> avr32: 2.6.19-rc1 [alive] >> blackfin: 2.6.22-rc1 [alive] >> mn10300: 2.6.25-rc1 [alive] >> microblaze: 2.6.30-rc2 [alive] >> score: 2.6.32-rc1 [abandoned][cloned off mips] >> tile: 2.6.36-rc1 [alive] >> unicore32: 2.6.39-rc1 [alive][cloned off arm] >> openrisc: 3.1-rc1 [alive] >> hexagon: 3.2-rc1 [alive] >> c6x: 3.3-rc1 [alive] >> arc: 3.9-rc1 [alive] >> metag: 3.9-rc1 [alive] >> >> Frankly, I would've expected score and lefotvers of sh64 (aka sh5) to be >> the first against the wall - h8300 was a bit surprising... >> > > Great summary. > > There seemed to be a consensus to remove h8300, at least so far and sufficiently > enough for me to ask Stephen to add the removal branch to linux-next. > We'll see if that triggers any further responses. > > With score, I am not entirely sure. I got one Ack for the removal, but > on the other side the score maintainers came back and claimed they would > still support it. We'll see if anything changes in practice. I am still > not sure if I should ask for the removal branch to be added to linux-next. > Frankly I thought I might jump the gun here more than with h8300. > > Either case, what to ultimately do with those two architectures will be > up to the community to decide. > > Guenter > Thanks again. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html