|
From: Maynard J. <may...@us...> - 2011-02-25 20:50:53
|
Hello, Julian, I'm working on an update to valgrind to support IBM Power ISA 2.06 (i.e., POWER7). There are ~200 new instructions, so this will be a major piece of work -- and a lot of lines of code. I propose to you that I submit the changes in 3 stages: 1. Support for instructions used by power7-tuned GLIBC libraries (36 instructions) 2. Support for instructions used by LAMP stack programs, built with -mcpu=power7 (~80 instructions) 3. Support for remaining ~80 instructions I have stage 1 nearly complete. This is the most critical to be done first, since developers working on RHEL6/POWER7 or SLES11-SP1/POWER7 will automatically link with the power7-tuned libc (and perhaps others) when they compile/link their programs. The new VSX instruction set is used extensively in libc on POWER7, so there's very little a program can do without libc using some VSX instructions. If this proposal is agreeable to you, I could open a bug report and attach the first code patch and test patch when I'm ready. I would open new bugs for each of the other two stages. Thanks. -Maynard |
|
From: Bart V. A. <bva...@ac...> - 2011-02-26 13:46:40
|
On Fri, Feb 25, 2011 at 9:51 PM, Maynard Johnson <may...@us...> wrote: > Hello, Julian, > I'm working on an update to valgrind to support IBM Power ISA 2.06 (i.e., POWER7). There are ~200 new instructions, so this will be a major piece of work -- and a lot of lines of code. I propose to you that I submit the changes in 3 stages: > > 1. Support for instructions used by power7-tuned GLIBC libraries (36 instructions) > 2. Support for instructions used by LAMP stack programs, built with -mcpu=power7 (~80 instructions) > 3. Support for remaining ~80 instructions > > I have stage 1 nearly complete. This is the most critical to be done first, since developers working on RHEL6/POWER7 or SLES11-SP1/POWER7 will automatically link with the power7-tuned libc (and perhaps others) when they compile/link their programs. The new VSX instruction set is used extensively in libc on POWER7, so there's very little a program can do without libc using some VSX instructions. > > If this proposal is agreeable to you, I could open a bug report and attach the first code patch and test patch when I'm ready. I would open new bugs for each of the other two stages. Hello Julian, Maybe it would be easier for the people who are porting Valgrind if both Valgrind and VEX would be available in a public git repository ? Instead of filing patches in the KDE bugzilla people who are porting Valgrind could set up a clone of the public Valgrind git repository and work in that repository. That would not only make reviewing those patches easier but would also make merging them easier -- all that would be necessary to merge such work is to issue a "git pull" request. A brief guide about how to import a Subversion repository into git can be found here: http://help.github.com/svn-importing/. Bart. |
|
From: Christian B. <bor...@de...> - 2011-03-02 11:45:51
|
Am 26.02.2011 14:46, schrieb Bart Van Assche: > Hello Julian, > > Maybe it would be easier for the people who are porting Valgrind if > both Valgrind and VEX would be available in a public git repository ? > Instead of filing patches in the KDE bugzilla people who are porting > Valgrind could set up a clone of the public Valgrind git repository > and work in that repository. That would not only make reviewing those > patches easier but would also make merging them easier -- all that > would be necessary to merge such work is to issue a "git pull" > request. A brief guide about how to import a Subversion repository > into git can be found here: http://help.github.com/svn-importing/. I second Barts opinion. Git (or mercurial) would allow private branches and Julian doesnt have to do anything to make that work (e.g. setting up the svn users). This would help in several cases: 1. For example after we merge the s390 port (hint hint :-) ) I certainly have additional patches later on (new cpus etc.) but some aspects are to big to communicate efficiently via patches. One example is decimal floating point. Its available on power and s390 (with some plans for x86 as well AFAIK) so it would certainly make sense that Maynard and myself would work out the necessary common code changes to work for both system before we bother you. So we could have a decimal floating point tree where Power and s390x can work together until we are satisfied with the result. 2. Another potential benefit would be that Julian could spread the maintenance work among other people. e.g. we could have a trivial bug fix tree maintained by someone you trust and you would just pull once in a while. Christian |
|
From: Florian K. <br...@ac...> - 2011-03-03 00:33:52
|
On 03/02/2011 06:45 AM, Christian Borntraeger wrote: > > I second Barts opinion. Git (or mercurial) would allow private branches > and Julian doesnt have to do anything to make that work (e.g. setting up > the svn users). svn allows restricting accesses to branches and it's not all that complex: http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.pathbasedauthz It's probably less work doing this than setting up and synching an additional repository. Although I wouldn't mind seeing valgrind move to git altogether. > This would help in several cases: It would also help with the s390 port maintenance. Most of my patches will be in VEX and I wouldn't be able to check them into mainline. AFAICT Julian is the only one who can make changes there. Unless that changes, the current setup requires me to maintain a patch queue for VEX changes which is less than ideal because it's clumsy and error prone. Not to mention synching those patches with collaborators. That is what I currently do and it isn't very attractive. Florian |
|
From: Bart V. A. <bva...@ac...> - 2011-03-03 17:45:05
|
On Wed, Mar 2, 2011 at 12:45 PM, Christian Borntraeger <bor...@de...> wrote: > Am 26.02.2011 14:46, schrieb Bart Van Assche: >> Hello Julian, >> >> Maybe it would be easier for the people who are porting Valgrind if >> both Valgrind and VEX would be available in a public git repository ? >> Instead of filing patches in the KDE bugzilla people who are porting >> Valgrind could set up a clone of the public Valgrind git repository >> and work in that repository. That would not only make reviewing those >> patches easier but would also make merging them easier -- all that >> would be necessary to merge such work is to issue a "git pull" >> request. A brief guide about how to import a Subversion repository >> into git can be found here: http://help.github.com/svn-importing/. > > I second Barts opinion. Git (or mercurial) would allow private branches > and Julian doesnt have to do anything to make that work (e.g. setting up > the svn users). > This would help in several cases: > 1. For example after we merge the s390 port (hint hint :-) ) I certainly > have additional patches later on (new cpus etc.) but some aspects are to > big to communicate efficiently via patches. One example is decimal floating > point. Its available on power and s390 (with some plans for x86 as well > AFAIK) so it would certainly make sense that Maynard and myself would work > out the necessary common code changes to work for both system before we > bother you. So we could have a decimal floating point tree where Power > and s390x can work together until we are satisfied with the result. > 2. Another potential benefit would be that Julian could spread the maintenance > work among other people. e.g. we could have a trivial bug fix tree maintained > by someone you trust and you would just pull once in a while. A middle way could be to set up an internal git repository, import the Valgrind source code in it via e.g. svn2git and make the results available as a patch attached to a bugzilla entry. More information about svn2git can be found here: https://github.com/nirvdrum/svn2git#readme. That should suit everyone's needs. Bart. |
|
From: Julian S. <js...@ac...> - 2011-03-02 09:43:25
|
Maynard, Yes, please open a bug report and attach the stage 1 patch to it. New bugs for the other two stages also sounds good. J On Friday, February 25, 2011, Maynard Johnson wrote: > Hello, Julian, > I'm working on an update to valgrind to support IBM Power ISA 2.06 (i.e., > POWER7). There are ~200 new instructions, so this will be a major piece > of work -- and a lot of lines of code. I propose to you that I submit > the changes in 3 stages: > > 1. Support for instructions used by power7-tuned GLIBC libraries (36 > instructions) 2. Support for instructions used by LAMP stack programs, > built with -mcpu=power7 (~80 instructions) 3. Support for remaining ~80 > instructions > > I have stage 1 nearly complete. This is the most critical to be done > first, since developers working on RHEL6/POWER7 or SLES11-SP1/POWER7 will > automatically link with the power7-tuned libc (and perhaps others) when > they compile/link their programs. The new VSX instruction set is used > extensively in libc on POWER7, so there's very little a program can do > without libc using some VSX instructions. > > If this proposal is agreeable to you, I could open a bug report and attach > the first code patch and test patch when I'm ready. I would open new bugs > for each of the other two stages. > > Thanks. > > -Maynard > > > --------------------------------------------------------------------------- > --- Free Software Download: Index, Search & Analyze Logs and other IT data > in Real-Time with Splunk. Collect, index and harness all the fast moving > IT data generated by your applications, servers and devices whether > physical, virtual or in the cloud. Deliver compliance at lower cost and > gain new business insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |