shifts on 64bit ints

shifts on 64bit ints

[Thomas Graichen]

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/

Re: shifts on 64bit ints

[David Edelsohn]

	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/

Re: shifts on 64bit ints

[Franz Sirl]

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/

Re: shifts on 64bit ints

[Takashi Oe]

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/

Re: shifts on 64bit ints

[Takashi Oe]

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/

Re: shifts on 64bit ints

[Thomas Graichen]

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/

Re: shifts on 64bit ints

[Gabriel Paubert]

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/

Re: shifts on 64bit ints

[David Edelsohn]

>>>>> 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/

Re: shifts on 64bit ints

[Kevin B. Hendricks]

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/

Getting things in... Was: Re: shifts on 64bit ints

[Tom Gall]

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/

Re: Getting things in... Was: Re: shifts on 64bit ints

[David Edelsohn]

>>>>> 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/

Re: Getting things in... Was: Re: shifts on 64bit ints

[Tom Gall]

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/

Re: Getting things in... Was: Re: shifts on 64bit ints

[Benjamin Herrenschmidt]

>
>  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/

Re: Getting things in... Was: Re: shifts on 64bit ints

[Takashi Oe]

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/

Re: Getting things in... Was: Re: shifts on 64bit ints

[Hendricks, Kevin]

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/

Re: Getting things in... Was: Re: shifts on 64bit ints

[Takashi Oe]

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/

Re: Getting things in... Was: Re: shifts on 64bit ints

[Michael Schmitz]

>
> > 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/

Re: Getting things in... Was: Re: shifts on 64bit ints

[Paul Mackerras]

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/

Re: Getting things in... Was: Re: shifts on 64bit ints

[Geert Uytterhoeven]

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/