* shifts on 64bit ints @ 2000-08-03 22:38 ` Thomas Graichen 2000-08-03 23:02 ` David Edelsohn 0 siblings, 1 reply; 19+ messages in thread From: Thomas Graichen @ 2000-08-03 22:38 UTC (permalink / raw) To: linuxppc-dev while trying to debug the sgi xfs code on the ppc i ran across the following thing which looks a bit like a bug to me - maybe some- one here can confirm - even better describe or solve this (this for now the reason - don't know if the last or not - why the sgi xfs code does not run on the ppc so far) ok - now the story - let's have a look at the following code: unsigned int myint; for (myint = 0; myint < 64; myint++) { printf("Mask %d is ",myint); printf("0x%8x", (int)((1LL << myint) >> 32)); printf("%8x - ", (int)(1LL << myint)); printf("0x%8x", (int)(~(1LL << myint) >> 32)); printf("%8x\n", (int)(~(1LL << myint))); } which should do about the same as shifting a bit through a 64bit (long long - LL) int and print the result for each step and the inverse of it - it is a bit more complicated (the 32 shifts) be- cause there seems to be no %llx support for printk so i had to work around it this way - i hope it is right that way - so basically it is the function of for (myint = 0; myint < 64; myint++) { printf("Mask %d is ",myint); printf("0x%llx - ", (1LL << myint)); printf("%llx\n", ~(1LL << myint)); } ok - if you compile it on i386 and on ppc in userland and in the kernel you get the following results: ... Mask 29 is 0x 020000000 - 0xffffffffdfffffff Mask 30 is 0x 040000000 - 0xffffffffbfffffff Mask 31 is 0x 080000000 - 0xffffffff7fffffff Mask 32 is 0x 1 0 - 0xfffffffeffffffff Mask 33 is 0x 2 0 - 0xfffffffdffffffff Mask 34 is 0x 4 0 - 0xfffffffbffffffff ... on i386 and ppc userland and i386 in the kernel - and this is i think what one would expect to get as the result - but in the kernel on ppc you get: ... Mask 29 is 0x 020000000 - 0xffffffffdfffffff Mask 30 is 0x 040000000 - 0xffffffffbfffffff Mask 31 is 0x 080000000 - 0xffffffff7fffffff Mask 32 is 0x 1 0 - 0xfffffffeffffffff Mask 33 is 0x 0 0 - 0xffffffffffffffff Mask 34 is 0x 0 0 - 0xffffffffffffffff ... which is a bit confusing to me and i think it is a bug some- where - any shift greater than 32 gives trash ... can anyone confirm this or have an idea or solution to this ? btw. if you shift 33 times by one instead of 33 at once it works fine ... btw. this is on the sgi xfs tree from oss.sgi.com with some patches to get it working on ppc from http://innominate.org/~graichen/projects/xfs-ppc/ so basically 2.4.0-test5 ... a lot of thanks in advance t p.s.: am i right that there is no simple way to print 64bit with printk (no %xll etc.) - or do i just not know the trick ? -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 web: http://innominate.de ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: shifts on 64bit ints 2000-08-03 22:38 ` shifts on 64bit ints Thomas Graichen @ 2000-08-03 23:02 ` David Edelsohn 2000-08-03 23:54 ` Franz Sirl 0 siblings, 1 reply; 19+ messages in thread From: David Edelsohn @ 2000-08-03 23:02 UTC (permalink / raw) To: Thomas Graichen; +Cc: linuxppc-dev First, I would suggest that you use a printf format like "%08x" for better legibility. Second, I tried your example with gcc-2.95.2 on PowerPC AIX gcc-2.95.2 on PowrePC Linux, and a recent development snapshot of GCC with various optimization levels (you did not specify what options you used to compile the testcase) and I consistently saw the following output: Mask 29 is 0x0000000020000000 - 0xffffffffdfffffff Mask 30 is 0x0000000040000000 - 0xffffffffbfffffff Mask 31 is 0x0000000080000000 - 0xffffffff7fffffff Mask 32 is 0x0000000100000000 - 0xfffffffeffffffff Mask 33 is 0x0000000200000000 - 0xfffffffdffffffff Mask 34 is 0x0000000400000000 - 0xfffffffbffffffff You appear to have a problem, but it is local to your system (could be toolchain or C library as well). David ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: shifts on 64bit ints 2000-08-03 23:02 ` David Edelsohn @ 2000-08-03 23:54 ` Franz Sirl 2000-08-04 0:40 ` Takashi Oe 0 siblings, 1 reply; 19+ messages in thread From: Franz Sirl @ 2000-08-03 23:54 UTC (permalink / raw) To: David Edelsohn; +Cc: Thomas Graichen, linuxppc-dev At 01:02 04.08.00, David Edelsohn wrote: > First, I would suggest that you use a printf format like "%08x" >for better legibility. > > Second, I tried your example with gcc-2.95.2 on PowerPC AIX >gcc-2.95.2 on PowrePC Linux, and a recent development snapshot of GCC with >various optimization levels (you did not specify what options you used to >compile the testcase) and I consistently saw the following output: > >Mask 29 is 0x0000000020000000 - 0xffffffffdfffffff >Mask 30 is 0x0000000040000000 - 0xffffffffbfffffff >Mask 31 is 0x0000000080000000 - 0xffffffff7fffffff >Mask 32 is 0x0000000100000000 - 0xfffffffeffffffff >Mask 33 is 0x0000000200000000 - 0xfffffffdffffffff >Mask 34 is 0x0000000400000000 - 0xfffffffbffffffff > > You appear to have a problem, but it is local to your system >(could be toolchain or C library as well). Oh no!! It's even worse! The kernel implementation of ashldi3, ashrdi3 and lshrdi3 seems broken, see this code in arch/ppc/kernel/misc.S: /* * Extended precision shifts * * R3/R4 has 64 bit value * R5 has shift count * result in R3/R4 * * ashrdi3: XXXYYY/ZZZAAA -> SSSXXX/YYYZZZ * ashldi3: XXXYYY/ZZZAAA -> YYYZZZ/AAA000 * lshrdi3: XXXYYY/ZZZAAA -> 000XXX/YYYZZZ */ _GLOBAL(__ashrdi3) li r6,32 sub r6,r6,r5 slw r7,r3,r6 /* isolate YYY */ srw r4,r4,r5 /* isolate ZZZ */ or r4,r4,r7 /* YYYZZZ */ sraw r3,r3,r5 /* SSSXXX */ blr _GLOBAL(__ashldi3) li r6,32 sub r6,r6,r5 srw r7,r4,r6 /* isolate ZZZ */ slw r4,r4,r5 /* AAA000 */ slw r3,r3,r5 /* YYY--- */ or r3,r3,r7 /* YYYZZZ */ blr _GLOBAL(__lshrdi3) li r6,32 sub r6,r6,r5 slw r7,r3,r6 /* isolate YYY */ srw r4,r4,r5 /* isolate ZZZ */ or r4,r4,r7 /* YYYZZZ */ srw r3,r3,r5 /* 000XXX */ blr I don't see how these can handle shift's >=32... Somebody should fix that... Franz. ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: shifts on 64bit ints 2000-08-03 23:54 ` Franz Sirl @ 2000-08-04 0:40 ` Takashi Oe 2000-08-04 0:50 ` Takashi Oe 2000-08-04 9:21 ` Gabriel Paubert 0 siblings, 2 replies; 19+ messages in thread From: Takashi Oe @ 2000-08-04 0:40 UTC (permalink / raw) To: Franz Sirl; +Cc: David Edelsohn, Thomas Graichen, linuxppc-dev On Fri, 4 Aug 2000, Franz Sirl wrote: > Oh no!! It's even worse! The kernel implementation of ashldi3, ashrdi3 and > lshrdi3 seems broken, see this code in arch/ppc/kernel/misc.S: The brokenness of those implementations has been noted by Gabriel a long time ago, and I believe he even sent a fix to this list once. For some unknown reasons, it has largely been ignored. I think I can dig out his patch if I try hard though. Takashi Oe ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: shifts on 64bit ints 2000-08-04 0:40 ` Takashi Oe @ 2000-08-04 0:50 ` Takashi Oe 2000-08-04 7:16 ` Thomas Graichen 2000-08-04 9:21 ` Gabriel Paubert 1 sibling, 1 reply; 19+ messages in thread From: Takashi Oe @ 2000-08-04 0:50 UTC (permalink / raw) To: Franz Sirl; +Cc: David Edelsohn, Thomas Graichen, linuxppc-dev On Thu, 3 Aug 2000, Takashi Oe wrote: > On Fri, 4 Aug 2000, Franz Sirl wrote: > > > Oh no!! It's even worse! The kernel implementation of ashldi3, ashrdi3 and > > lshrdi3 seems broken, see this code in arch/ppc/kernel/misc.S: > > The brokenness of those implementations has been noted by Gabriel a long > time ago, and I believe he even sent a fix to this list once. For some > unknown reasons, it has largely been ignored. I think I can dig out his > patch if I try hard though. Ok, found it: http://lists.linuxppc.org/listarcs/linuxppc-dev/199904/msg00189.html more than a year ago.... Takashi Oe ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: shifts on 64bit ints 2000-08-04 0:50 ` Takashi Oe @ 2000-08-04 7:16 ` Thomas Graichen 0 siblings, 0 replies; 19+ messages in thread From: Thomas Graichen @ 2000-08-04 7:16 UTC (permalink / raw) To: linuxppc-dev Takashi Oe <toe@unlserve.unl.edu> wrote: > On Thu, 3 Aug 2000, Takashi Oe wrote: >> On Fri, 4 Aug 2000, Franz Sirl wrote: >> >> > Oh no!! It's even worse! The kernel implementation of ashldi3, ashrdi3 and >> > lshrdi3 seems broken, see this code in arch/ppc/kernel/misc.S: >> >> The brokenness of those implementations has been noted by Gabriel a long >> time ago, and I believe he even sent a fix to this list once. For some >> unknown reasons, it has largely been ignored. I think I can dig out his >> patch if I try hard though. > Ok, found it: > http://lists.linuxppc.org/listarcs/linuxppc-dev/199904/msg00189.html nks - i'll try (think and hope :-) that this fixes the problems with xfs ... will mail the result here later t -- thomas.graichen@innominate.de Technical Director innominate AG Clustering & Security networking people tel: +49.30.308806-13 fax: -77 http://innominate.de ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: shifts on 64bit ints 2000-08-04 0:40 ` Takashi Oe 2000-08-04 0:50 ` Takashi Oe @ 2000-08-04 9:21 ` Gabriel Paubert 2000-08-04 15:18 ` David Edelsohn 1 sibling, 1 reply; 19+ messages in thread From: Gabriel Paubert @ 2000-08-04 9:21 UTC (permalink / raw) To: Takashi Oe; +Cc: Franz Sirl, David Edelsohn, Thomas Graichen, linuxppc-dev On Thu, 3 Aug 2000, Takashi Oe wrote: > > On Fri, 4 Aug 2000, Franz Sirl wrote: > > > Oh no!! It's even worse! The kernel implementation of ashldi3, ashrdi3 and > > lshrdi3 seems broken, see this code in arch/ppc/kernel/misc.S: > > The brokenness of those implementations has been noted by Gabriel a long > time ago, and I believe he even sent a fix to this list once. For some > unknown reasons, it has largely been ignored. I think I can dig out his > patch if I try hard though. <rant> Don't worry, I am by now largely accustomed to the fact that even my most obvious bugfixes are systematically ignored :-( And in this precise case there is no excuse, it is a localized patch that does exactly one thing and does it correctly. </rant> Here is the corresponding part of misc.S in my source (based on kernel.org 2.4.0-test5, but it does not change anything). Note that the code is largely taken from the PPC manual examples for multiple precision shifts (with a tweak to make ashrdi branchless), why reinvent the wheel when IBM and Motorola have already done it: /* * Extended precision shifts. * * Updated to be valid for shift counts from 0 to 63 inclusive. * -- Gabriel * * R3/R4 has 64 bit value * R5 has shift count * result in R3/R4 * * ashrdi3: arithmetic right shift (sign propagation) * ashldi3: logical shift left * lshrdi3: logical right shift */ _GLOBAL(__ashrdi3) subfic r6,r5,32 srw r4,r4,r5 # LSW = count > 31 ? 0 : LSW >> count addi r7,r5,32 # could be xori, or addi with -32 slw r6,r3,r6 # t1 = count > 31 ? 0 : MSW << (32-count) rlwinm r8,r7,0,32 # t3 = (count < 32) ? 32 : 0 sraw r7,r3,r7 # t2 = MSW >> (count-32) or r4,r4,r6 # LSW |= t1 slw r7,r7,r8 # t2 = (count < 32) ? 0 : t2 sraw r3,r3,r5 # MSW = MSW >> count or r4,r4,r7 # LSW |= t2 blr _GLOBAL(__ashldi3) subfic r6,r5,32 slw r3,r3,r5 # MSW = count > 31 ? 0 : MSW << count addi r7,r5,32 # could be xori, or addi with -32 srw r6,r4,r6 # t1 = count > 31 ? 0 : LSW >> (32-count) slw r7,r4,r7 # t2 = count < 32 ? 0 : LSW << (count-32) or r3,r3,r6 # MSW |= t1 slw r4,r4,r5 # LSW = LSW << count or r3,r3,r7 # MSW |= t2 blr _GLOBAL(__lshrdi3) subfic r6,r5,32 srw r4,r4,r5 # LSW = count > 31 ? 0 : LSW >> count addi r7,r5,32 # could be xori, or addi with -32 slw r6,r3,r6 # t1 = count > 31 ? 0 : MSW << (32-count) srw r7,r3,r7 # t2 = count < 32 ? 0 : MSW >> (count-32) or r4,r4,r6 # LSW |= t1 srw r3,r3,r5 # MSW = MSW >> count or r4,r4,r7 # LSW |= t2 blr Would some kind soul push it to the bk tree (I don't ant push access to the bk tree, my link is too slow and I would lock the reepository for eons even for small accesses). Somebody wants to volunteer to do it ? I plan to send a lot of small obvious bugfixes in the next 3-4 weeks, the diffs between my tree and the official one now run in the megabyte range, and this is too much (would the BitKeeper tree accept the VME patches and PrePboot BTW ?) What I would for one like to see is that people that write a patch that may affect other machines than their own first publish it on this list and wait a couple of days for comment and test results before pushing it to the official source tree, somewhat like what happens on gcc-patches. Almost every time I apply a new official patch, something silly breaks my machines. I'm now accustomed and it's much easier thanks to BitKeeper (although I base all my work on kernel.org's tree, just built a BK repository out of it). A little discipline in this respect could only help given the variety of PPC machines. Oh well, I can always dream... Regards, Gabriel. ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: shifts on 64bit ints 2000-08-04 9:21 ` Gabriel Paubert @ 2000-08-04 15:18 ` David Edelsohn 2000-08-04 15:28 ` Kevin B. Hendricks 2000-08-04 16:06 ` Getting things in... Was: " Tom Gall 0 siblings, 2 replies; 19+ messages in thread From: David Edelsohn @ 2000-08-04 15:18 UTC (permalink / raw) To: Gabriel Paubert; +Cc: Takashi Oe, Franz Sirl, Thomas Graichen, linuxppc-dev >>>>> Gabriel Paubert writes: Gabriel> I plan to send a lot of small obvious bugfixes in the next 3-4 weeks, the Gabriel> diffs between my tree and the official one now run in the megabyte range, Gabriel> and this is too much (would the BitKeeper tree accept the VME patches and Gabriel> PrePboot BTW ?) Gabriel> What I would for one like to see is that people that write a patch that Gabriel> may affect other machines than their own first publish it on this list and Gabriel> wait a couple of days for comment and test results before pushing it to Gabriel> the official source tree, somewhat like what happens on gcc-patches. linuxppc-dev is not necessarily a patch submission mailinglist. Until PowerPC Linux development has such a thing, I think that it is better to coordinate with and directly send patches to someone with write-access who can apply the patches instead of throwing them up in the air and hoping that someone catches them. David ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: shifts on 64bit ints 2000-08-04 15:18 ` David Edelsohn @ 2000-08-04 15:28 ` Kevin B. Hendricks 2000-08-04 16:06 ` Getting things in... Was: " Tom Gall 1 sibling, 0 replies; 19+ messages in thread From: Kevin B. Hendricks @ 2000-08-04 15:28 UTC (permalink / raw) To: David Edelsohn Cc: Gabriel Paubert, Takashi Oe, Franz Sirl, Thomas Graichen, linuxppc-dev Hi, But if they are not cc'd to the linuxppc-dev list then we do need some sort of CHANGELOG process going on. None of the rsync trees seem to do any versioning. Possibly we should have our own kernel mailing lists for patches and things. Kevin David Edelsohn wrote: > > >>>>> Gabriel Paubert writes: > > Gabriel> I plan to send a lot of small obvious bugfixes in the next 3-4 weeks, the > Gabriel> diffs between my tree and the official one now run in the megabyte range, > Gabriel> and this is too much (would the BitKeeper tree accept the VME patches and > Gabriel> PrePboot BTW ?) > > Gabriel> What I would for one like to see is that people that write a patch that > Gabriel> may affect other machines than their own first publish it on this list and > Gabriel> wait a couple of days for comment and test results before pushing it to > Gabriel> the official source tree, somewhat like what happens on gcc-patches. > > linuxppc-dev is not necessarily a patch submission mailinglist. > Until PowerPC Linux development has such a thing, I think that it is > better to coordinate with and directly send patches to someone with > write-access who can apply the patches instead of throwing them up in the > air and hoping that someone catches them. > > David > ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Getting things in... Was: Re: shifts on 64bit ints 2000-08-04 15:18 ` David Edelsohn 2000-08-04 15:28 ` Kevin B. Hendricks @ 2000-08-04 16:06 ` Tom Gall 2000-08-04 16:26 ` David Edelsohn 2000-08-04 17:49 ` Benjamin Herrenschmidt 1 sibling, 2 replies; 19+ messages in thread From: Tom Gall @ 2000-08-04 16:06 UTC (permalink / raw) To: Gabriel Paubert Cc: David Edelsohn, Takashi Oe, Franz Sirl, Thomas Graichen, linuxppc-dev David Edelsohn wrote: > > >>>>> Gabriel Paubert writes: > > Gabriel> I plan to send a lot of small obvious bugfixes in the next 3-4 weeks, the > Gabriel> diffs between my tree and the official one now run in the megabyte range, > Gabriel> and this is too much (would the BitKeeper tree accept the VME patches and > Gabriel> PrePboot BTW ?) > > Gabriel> What I would for one like to see is that people that write a patch that > Gabriel> may affect other machines than their own first publish it on this list and > Gabriel> wait a couple of days for comment and test results before pushing it to > Gabriel> the official source tree, somewhat like what happens on gcc-patches. I must confess this is one of those areas where I wish we were on CVS instead of BK. If you want feel free to send your patches my way and I'll be sure that they get in. I can at least test things on my prep, chrp rs6000s and even my power mac. > linuxppc-dev is not necessarily a patch submission mailinglist. > Until PowerPC Linux development has such a thing, I think that it is > better to coordinate with and directly send patches to someone with > write-access who can apply the patches instead of throwing them up in the > air and hoping that someone catches them. This can be a good thing or a bad thing tho. I'd rather like to see patches posted to the list. Granted there's some line there where they simply get too big and a link is better. At least with posting to the list everyone has the chance to comment and better yet test them out! Regards, Tom > David > -- Hakuna Matata, Tom ----------------------------------------------------------- Linux Guy "My heart is human, my blood is boiling, tgall@uswest.net my brain IBM" -- Mr Roboto, Styxx ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Getting things in... Was: Re: shifts on 64bit ints 2000-08-04 16:06 ` Getting things in... Was: " Tom Gall @ 2000-08-04 16:26 ` David Edelsohn 2000-08-04 16:30 ` Tom Gall 2000-08-04 17:49 ` Benjamin Herrenschmidt 1 sibling, 1 reply; 19+ messages in thread From: David Edelsohn @ 2000-08-04 16:26 UTC (permalink / raw) To: Tom Gall Cc: Gabriel Paubert, Takashi Oe, Franz Sirl, Thomas Graichen, linuxppc-dev >>>>> Tom Gall writes: >> linuxppc-dev is not necessarily a patch submission mailinglist. >> Until PowerPC Linux development has such a thing, I think that it is >> better to coordinate with and directly send patches to someone with >> write-access who can apply the patches instead of throwing them up in the >> air and hoping that someone catches them. Tom> This can be a good thing or a bad thing tho. I'd rather like to see Tom> patches posted to the list. Granted there's some line there where they Tom> simply get too big and a link is better. At least with posting to the Tom> list everyone has the chance to comment and better yet test them out! I did not mean to send patches to someone *instead* of sending them to the mailinglist. I meant that sending them to the mailinglist solely as a way of proposing that a patch be merged into the development tree does not make it clear what action should be taken. David ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Getting things in... Was: Re: shifts on 64bit ints 2000-08-04 16:26 ` David Edelsohn @ 2000-08-04 16:30 ` Tom Gall 0 siblings, 0 replies; 19+ messages in thread From: Tom Gall @ 2000-08-04 16:30 UTC (permalink / raw) To: David Edelsohn; +Cc: linuxppc-dev David Edelsohn wrote: > > Tom> This can be a good thing or a bad thing tho. I'd rather like to see > Tom> patches posted to the list. Granted there's some line there where they > Tom> simply get too big and a link is better. At least with posting to the > Tom> list everyone has the chance to comment and better yet test them out! > > I did not mean to send patches to someone *instead* of sending > them to the mailinglist. I meant that sending them to the mailinglist > solely as a way of proposing that a patch be merged into the development > tree does not make it clear what action should be taken. Hi David, Ooops sorry about that. Had a tooth out yesterday so my brain isn't exactly in the best of shape today. Regards, Tom > David -- Hakuna Matata, Tom ----------------------------------------------------------- Linux Guy "My heart is human, my blood is boiling, tgall@uswest.net my brain IBM" -- Mr Roboto, Styxx ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Getting things in... Was: Re: shifts on 64bit ints 2000-08-04 16:06 ` Getting things in... Was: " Tom Gall 2000-08-04 16:26 ` David Edelsohn @ 2000-08-04 17:49 ` Benjamin Herrenschmidt 2000-08-04 18:32 ` Takashi Oe ` (2 more replies) 1 sibling, 3 replies; 19+ messages in thread From: Benjamin Herrenschmidt @ 2000-08-04 17:49 UTC (permalink / raw) To: Tom Gall, linuxppc-dev > > I must confess this is one of those areas where I wish we were on CVS >instead of BK. > > If you want feel free to send your patches my way and I'll be sure >that they get in. I can at least test things on my prep, chrp rs6000s >and even my power mac. > >> linuxppc-dev is not necessarily a patch submission mailinglist. >> Until PowerPC Linux development has such a thing, I think that it is >> better to coordinate with and directly send patches to someone with >> write-access who can apply the patches instead of throwing them up in the >> air and hoping that someone catches them. > > This can be a good thing or a bad thing tho. I'd rather like to see >patches posted to the list. Granted there's some line there where they >simply get too big and a link is better. At least with posting to the >list everyone has the chance to comment and better yet test them out! I'm an horribly bad web designer, but one cool thing to do if someone is good at it, would be a web-pased patch repository. You send patches with a web form (eventually an upload mecanism) along with your email, a comment, etc..., they get assigned a patch number automatically, anybody can consult the database, and people with write access to BK can mark them (accepted, refused, postponed, ... along with a comment) once they have been handled. Any volunteer to design such a site ? Ben. ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Getting things in... Was: Re: shifts on 64bit ints 2000-08-04 17:49 ` Benjamin Herrenschmidt @ 2000-08-04 18:32 ` Takashi Oe 2000-08-04 18:52 ` Hendricks, Kevin 2000-08-05 5:42 ` Paul Mackerras 2000-08-05 11:51 ` Geert Uytterhoeven 2 siblings, 1 reply; 19+ messages in thread From: Takashi Oe @ 2000-08-04 18:32 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: Tom Gall, linuxppc-dev On Fri, 4 Aug 2000, Benjamin Herrenschmidt wrote: > I'm an horribly bad web designer, but one cool thing to do if someone is > good at it, would be a web-pased patch repository. You send patches with > a web form (eventually an upload mecanism) along with your email, a > comment, etc..., they get assigned a patch number automatically, anybody > can consult the database, and people with write access to BK can mark > them (accepted, refused, postponed, ... along with a comment) once they > have been handled. > > Any volunteer to design such a site ? What happened to the BK mailing list? Is it still closed for non-write access members of community? Or does it still exist? If the BK list were open to people who want to keep track of things, it can also serve as a patch bucket, since everybody who has the write access is subscribed to the list automatically. Also, the archive of the list can be used as CHANGELOG for rsync only people. I'm not really against the web site idea, but it's just that there won't be too many people submitting patches in the first place to warrent the extra administrative burden on developers with write access to BK, I would think. Takashi Oe ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Getting things in... Was: Re: shifts on 64bit ints 2000-08-04 18:32 ` Takashi Oe @ 2000-08-04 18:52 ` Hendricks, Kevin 2000-08-04 19:44 ` Takashi Oe 2000-08-04 20:10 ` Michael Schmitz 0 siblings, 2 replies; 19+ messages in thread From: Hendricks, Kevin @ 2000-08-04 18:52 UTC (permalink / raw) To: Takashi Oe; +Cc: Benjamin Herrenschmidt, Tom Gall, linuxppc-dev Hi, > I'm not really against the web site idea, but it's just that there won't > be too many people submitting patches in the first place to warrent the > extra administrative burden on developers with write access to BK, I would > think. I don't agree. A separate website is important. I don't work on the kernel directly but I have submitted patches here and there and have run into problems when testing/debugging the JDK that are kernel issues. I don't want write access to any tree, but I do need to see what patches are going in, what changed, the status of my own patches, etc. Also, I think we could easily modify any of the simple bugdatabase programs like bugzilla to do exactly what we want (instead of calling them bugs, call them patches, instead of fixed, call them accepted, etc) You could also create categories so that driver patches are separate from other patches easily with this type of software. We are getting more and more people contributing to the kernel process I think a simple modified bugtracking system linked to http://penguinppc.org could be easily made to serve this purpose without having/needing a whole new site. My two cents: Kevin ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Getting things in... Was: Re: shifts on 64bit ints 2000-08-04 18:52 ` Hendricks, Kevin @ 2000-08-04 19:44 ` Takashi Oe 2000-08-04 20:10 ` Michael Schmitz 1 sibling, 0 replies; 19+ messages in thread From: Takashi Oe @ 2000-08-04 19:44 UTC (permalink / raw) To: Hendricks, Kevin; +Cc: Benjamin Herrenschmidt, Tom Gall, linuxppc-dev On Fri, 4 Aug 2000, Hendricks, Kevin wrote: > > I'm not really against the web site idea, but it's just that there won't > > be too many people submitting patches in the first place to warrent the > > extra administrative burden on developers with write access to BK, I would > > think. > > I don't agree. A separate website is important. I don't work on the kernel > directly but I have submitted patches here and there and have run into problems > when testing/debugging the JDK that are kernel issues. Ok, on a second thought, I feel a patch repository is a good idea for users. I was originally not too excited about the idea because people who actually make the final decisions like Cort or Paul haven't said anything, and I'm not really positive that they can spend time on dealing with the patches accumulated in the repository in timely manner. Unless we have their blessing, the repository won't work for many of the patches, and we'll have to default to current method of non-method. [Well, at least Ben is willing, so I'm sure the repository will work for pmac specific patches, actually.] However, the repository will be good for users who compile kernels themselves or distribution makers. They can search for fixes for specific problems they are facing, and we can point users to look at the repository for patches. > > I don't want write access to any tree, but I do need to see what patches are > going in, what changed, the status of my own patches, etc. > > Also, I think we could easily modify any of the simple bugdatabase programs like > bugzilla to do exactly what we want (instead of calling them bugs, call them > patches, instead of fixed, call them accepted, etc) You could also create > categories so that driver patches are separate from other patches easily with > this type of software. I agree. It should be fairly easy to set up. > We are getting more and more people contributing to the kernel process I feel it's not many more than ten at any given time, if we only count kernel hackers without the write access who submit patches occasionally or regularly. Takashi Oe ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Getting things in... Was: Re: shifts on 64bit ints 2000-08-04 18:52 ` Hendricks, Kevin 2000-08-04 19:44 ` Takashi Oe @ 2000-08-04 20:10 ` Michael Schmitz 1 sibling, 0 replies; 19+ messages in thread From: Michael Schmitz @ 2000-08-04 20:10 UTC (permalink / raw) To: Hendricks, Kevin Cc: Takashi Oe, Benjamin Herrenschmidt, Tom Gall, linuxppc-dev > > > I'm not really against the web site idea, but it's just that there won't > > be too many people submitting patches in the first place to warrent the > > extra administrative burden on developers with write access to BK, I would > > think. > > I don't agree. A separate website is important. I don't work on the kernel > directly but I have submitted patches here and there and have run into problems > when testing/debugging the JDK that are kernel issues. > > I don't want write access to any tree, but I do need to see what patches are > going in, what changed, the status of my own patches, etc. Same for me. So far I've been sending patches to Paul or BenH but some list or web site as patch bucket would allow others to test that stuff. Michael ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Getting things in... Was: Re: shifts on 64bit ints 2000-08-04 17:49 ` Benjamin Herrenschmidt 2000-08-04 18:32 ` Takashi Oe @ 2000-08-05 5:42 ` Paul Mackerras 2000-08-05 11:51 ` Geert Uytterhoeven 2 siblings, 0 replies; 19+ messages in thread From: Paul Mackerras @ 2000-08-05 5:42 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: Tom Gall, linuxppc-dev Benjamin Herrenschmidt writes: > I'm an horribly bad web designer, but one cool thing to do if someone is > good at it, would be a web-pased patch repository. You send patches with > a web form (eventually an upload mecanism) along with your email, a > comment, etc..., they get assigned a patch number automatically, anybody > can consult the database, and people with write access to BK can mark > them (accepted, refused, postponed, ... along with a comment) once they > have been handled. Sounds exactly like the jitterbug site that Andrew Tridgell set up for the Linux kernel. Linus tried it for a while but unfortunately eventually decided he didn't like it enough. But for the rest of us it was great. Tridge even put in a "test patch" button for Linus that would rsync the current kernel tree, automagically unpack/decompress the patch, apply it and report any errors. I could ask Tridge to set up something like this for us. Paul. -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax paulus@linuxcare.com.au, http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Getting things in... Was: Re: shifts on 64bit ints 2000-08-04 17:49 ` Benjamin Herrenschmidt 2000-08-04 18:32 ` Takashi Oe 2000-08-05 5:42 ` Paul Mackerras @ 2000-08-05 11:51 ` Geert Uytterhoeven 2 siblings, 0 replies; 19+ messages in thread From: Geert Uytterhoeven @ 2000-08-05 11:51 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: Tom Gall, linuxppc-dev On Fri, 4 Aug 2000, Benjamin Herrenschmidt wrote: > I'm an horribly bad web designer, but one cool thing to do if someone is > good at it, would be a web-pased patch repository. You send patches with > a web form (eventually an upload mecanism) along with your email, a > comment, etc..., they get assigned a patch number automatically, anybody > can consult the database, and people with write access to BK can mark > them (accepted, refused, postponed, ... along with a comment) once they > have been handled. > > Any volunteer to design such a site ? It already exists for Samba, and once it was in a testing period for the Linux kernel (as maintained by Linus): Jitterbug. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2000-08-05 11:51 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <news-innominate.list.linux.ppc.dev@innominate.de>
2000-08-03 22:38 ` shifts on 64bit ints Thomas Graichen
2000-08-03 23:02 ` David Edelsohn
2000-08-03 23:54 ` Franz Sirl
2000-08-04 0:40 ` Takashi Oe
2000-08-04 0:50 ` Takashi Oe
2000-08-04 7:16 ` Thomas Graichen
2000-08-04 9:21 ` Gabriel Paubert
2000-08-04 15:18 ` David Edelsohn
2000-08-04 15:28 ` Kevin B. Hendricks
2000-08-04 16:06 ` Getting things in... Was: " Tom Gall
2000-08-04 16:26 ` David Edelsohn
2000-08-04 16:30 ` Tom Gall
2000-08-04 17:49 ` Benjamin Herrenschmidt
2000-08-04 18:32 ` Takashi Oe
2000-08-04 18:52 ` Hendricks, Kevin
2000-08-04 19:44 ` Takashi Oe
2000-08-04 20:10 ` Michael Schmitz
2000-08-05 5:42 ` Paul Mackerras
2000-08-05 11:51 ` Geert Uytterhoeven
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).