Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-03-07 Thread Roland McGrath
> On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote: > > > Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] > > > and [5] is also needed. > > > > It's not. The utrace_regset for the debugregs already has that behavior > > for those two words, so mapping all 8

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-03-07 Thread Roland McGrath
On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote: Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] and [5] is also needed. It's not. The utrace_regset for the debugregs already has that behavior for those two words, so mapping all 8 uarea words to

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-21 Thread Alexey Dobriyan
On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote: > > Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] > > and [5] is also needed. > > It's not. The utrace_regset for the debugregs already has that behavior > for those two words, so mapping all 8 uarea words to

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-21 Thread Alexey Dobriyan
On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote: Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] and [5] is also needed. It's not. The utrace_regset for the debugregs already has that behavior for those two words, so mapping all 8 uarea words to the

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-17 Thread Roland McGrath
> Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] > and [5] is also needed. It's not. The utrace_regset for the debugregs already has that behavior for those two words, so mapping all 8 uarea words to the regset is fine. Thanks, Roland - To unsubscribe from this list:

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-17 Thread Roland McGrath
Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4] and [5] is also needed. It's not. The utrace_regset for the debugregs already has that behavior for those two words, so mapping all 8 uarea words to the regset is fine. Thanks, Roland - To unsubscribe from this list: send

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-15 Thread Alexey Dobriyan
On Tue, Feb 13, 2007 at 04:05:30PM +0300, Alexey Dobriyan wrote: > On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: > > > 2. The following proggie renders box unusable in ~10 seconds (but not > > >mainline kernel where Ctrl+C will kill process). > > > > I haven't been able to

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-15 Thread Alexey Dobriyan
On Tue, Feb 13, 2007 at 04:05:30PM +0300, Alexey Dobriyan wrote: On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: 2. The following proggie renders box unusable in ~10 seconds (but not mainline kernel where Ctrl+C will kill process). I haven't been able to reproduce

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-13 Thread Alexey Dobriyan
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: > > We're aware of two regressions compared to mainline if ptrace is utrace: > > Thanks very much for bringing these to my attention. > > > 1) zero holes for PTRACE_PEEKUSR vanished. > > I've fixed this in the current patches.

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-13 Thread Alexey Dobriyan
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: > > 2. The following proggie renders box unusable in ~10 seconds (but not > >mainline kernel where Ctrl+C will kill process). > > I haven't been able to reproduce this so far on my test machine. I got > bored after about 10

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-13 Thread Alexey Dobriyan
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: 2. The following proggie renders box unusable in ~10 seconds (but not mainline kernel where Ctrl+C will kill process). I haven't been able to reproduce this so far on my test machine. I got bored after about 10 minutes

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-13 Thread Alexey Dobriyan
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote: We're aware of two regressions compared to mainline if ptrace is utrace: Thanks very much for bringing these to my attention. 1) zero holes for PTRACE_PEEKUSR vanished. I've fixed this in the current patches. Looking at

Re: -mm merge plans for 2.6.21

2007-02-12 Thread Doug Thompson
--- Andi Kleen <[EMAIL PROTECTED]> wrote: > > As to the size of the MCE code doing everything EDAC K8 does, that > is > > mostly true. BUT then the x86_64 MCE mechanism becomes the > exception > > path. > > Sorry you lost me on that one. > > -Andi In similiar manner of the original SATA

Re: -mm merge plans for 2.6.21

2007-02-12 Thread Andi Kleen
> I am currently developing enhancements to EDAC that provide for L1, L2, > etc cache ECC event harvesting, mce.c + mcelog do that already for all x86-64 cpus because that's all reported as standard x86 machine checks. > DMA ECC event harvest, interconnect > harvesting, and other

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-12 Thread Roland McGrath
> We're aware of two regressions compared to mainline if ptrace is utrace: Thanks very much for bringing these to my attention. > 1) zero holes for PTRACE_PEEKUSR vanished. I've fixed this in the current patches. > 2. The following proggie renders box unusable in ~10 seconds (but not >

Re: -mm merge plans for 2.6.21

2007-02-12 Thread Frederik Deweerdt
On Sat, Feb 10, 2007 at 11:04:48AM -0600, Robert Hancock wrote: > Frederik Deweerdt wrote: > >>How about this one instead then: > >Well, the warning you get is not that obvious: > >test.c: In function 'main': > >test.c:11: warning: 'deprecated_irqf' is deprecated > >And as far as I could test ...

Re: -mm merge plans for 2.6.21

2007-02-12 Thread Doug Thompson
--- Andi Kleen <[EMAIL PROTECTED]> wrote: > Alan <[EMAIL PROTECTED]> writes: > > > Please just push the EDAC K8 stuff. Andi will say "no" from now > until the > > end of time, but end users want it, distributions want it, and Andi > is > > not the EDAC maintainer so should consider himself

[PATCH x86 for review III] [24/29] x86_64: -mm merge plans for 2.6.21

2007-02-12 Thread Andi Kleen
From: Ralf Baechle <[EMAIL PROTECTED]> On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: > Which remembers me that I think that MIPS is using the non-compat version > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > syscall for some reason. Dunno.

utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-12 Thread Alexey Dobriyan
> utrace-utrace-tracehook.patch > utrace-utrace-tracehook-ia64.patch > utrace-utrace-tracehook-sparc64.patch > utrace-utrace-tracehook-s390.patch > utrace-utrace-regset.patch > utrace-utrace-regset-ia64.patch > utrace-utrace-regset-sparc64.patch > utrace-utrace-regset-s390.patch >

utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-12 Thread Alexey Dobriyan
utrace-utrace-tracehook.patch utrace-utrace-tracehook-ia64.patch utrace-utrace-tracehook-sparc64.patch utrace-utrace-tracehook-s390.patch utrace-utrace-regset.patch utrace-utrace-regset-ia64.patch utrace-utrace-regset-sparc64.patch utrace-utrace-regset-s390.patch utrace-utrace-core.patch

[PATCH x86 for review III] [24/29] x86_64: -mm merge plans for 2.6.21

2007-02-12 Thread Andi Kleen
From: Ralf Baechle [EMAIL PROTECTED] On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. Which

Re: -mm merge plans for 2.6.21

2007-02-12 Thread Doug Thompson
--- Andi Kleen [EMAIL PROTECTED] wrote: Alan [EMAIL PROTECTED] writes: Please just push the EDAC K8 stuff. Andi will say no from now until the end of time, but end users want it, distributions want it, and Andi is not the EDAC maintainer so should consider himself overruled on what

Re: -mm merge plans for 2.6.21

2007-02-12 Thread Frederik Deweerdt
On Sat, Feb 10, 2007 at 11:04:48AM -0600, Robert Hancock wrote: Frederik Deweerdt wrote: How about this one instead then: Well, the warning you get is not that obvious: test.c: In function 'main': test.c:11: warning: 'deprecated_irqf' is deprecated And as far as I could test ... which

Re: -mm merge plans for 2.6.21

2007-02-12 Thread Andi Kleen
I am currently developing enhancements to EDAC that provide for L1, L2, etc cache ECC event harvesting, mce.c + mcelog do that already for all x86-64 cpus because that's all reported as standard x86 machine checks. DMA ECC event harvest, interconnect harvesting, and other

Re: -mm merge plans for 2.6.21

2007-02-12 Thread Doug Thompson
--- Andi Kleen [EMAIL PROTECTED] wrote: As to the size of the MCE code doing everything EDAC K8 does, that is mostly true. BUT then the x86_64 MCE mechanism becomes the exception path. Sorry you lost me on that one. -Andi In similiar manner of the original SATA driver model, the

Re: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-12 Thread Roland McGrath
We're aware of two regressions compared to mainline if ptrace is utrace: Thanks very much for bringing these to my attention. 1) zero holes for PTRACE_PEEKUSR vanished. I've fixed this in the current patches. 2. The following proggie renders box unusable in ~10 seconds (but not mainline

Re: -mm merge plans for 2.6.21

2007-02-11 Thread Ralf Baechle
On Sun, Feb 11, 2007 at 05:14:46PM +0100, Heiko Carstens wrote: > Hmm.. so you don't need to do some fancy compat conversion for the sigset_t > that gets passed? Why is that? I don't get it... Ah, I finally get your point. Yes, that needs conversion. Ralf - To unsubscribe from this list:

Re: -mm merge plans for 2.6.21

2007-02-11 Thread Ralf Baechle
On Sun, Feb 11, 2007 at 04:33:41PM +0100, David Woodhouse wrote: > On Sat, 2007-02-10 at 21:34 +, Ralf Baechle wrote: > > Unfortunately struct epoll_event contains a gap so it bets on identical > > padding rules between native and compat ABI and anyway, padding is wasted > > space so the

Re: -mm merge plans for 2.6.21

2007-02-11 Thread Davide Libenzi
On Sun, 11 Feb 2007, Heiko Carstens wrote: > On Sat, Feb 10, 2007 at 09:34:47PM +, Ralf Baechle wrote: > > On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: > > > > > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > > > > Which remembers me that I think that MIPS is

Re: -mm merge plans for 2.6.21

2007-02-11 Thread Heiko Carstens
On Sat, Feb 10, 2007 at 09:34:47PM +, Ralf Baechle wrote: > On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: > > > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > > > Which remembers me that I think that MIPS is using the non-compat version > > > of sys_epoll_pwait

Re: -mm merge plans for 2.6.21

2007-02-11 Thread David Woodhouse
On Sat, 2007-02-10 at 21:34 +, Ralf Baechle wrote: > Unfortunately struct epoll_event contains a gap so it bets on identical > padding rules between native and compat ABI and anyway, padding is wasted > space so the struct members should have been swapped when this structure > was created. Oh

Re: -mm merge plans for 2.6.21

2007-02-11 Thread Andi Kleen
On Saturday 10 February 2007 22:05, Ralf Baechle wrote: > On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: > > > Which remembers me that I think that MIPS is using the non-compat version > > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > > syscall

Re: -mm merge plans for 2.6.21

2007-02-11 Thread Andi Kleen
On Saturday 10 February 2007 22:05, Ralf Baechle wrote: On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some

Re: -mm merge plans for 2.6.21

2007-02-11 Thread David Woodhouse
On Sat, 2007-02-10 at 21:34 +, Ralf Baechle wrote: Unfortunately struct epoll_event contains a gap so it bets on identical padding rules between native and compat ABI and anyway, padding is wasted space so the struct members should have been swapped when this structure was created. Oh

Re: -mm merge plans for 2.6.21

2007-02-11 Thread Heiko Carstens
On Sat, Feb 10, 2007 at 09:34:47PM +, Ralf Baechle wrote: On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat

Re: -mm merge plans for 2.6.21

2007-02-11 Thread Davide Libenzi
On Sun, 11 Feb 2007, Heiko Carstens wrote: On Sat, Feb 10, 2007 at 09:34:47PM +, Ralf Baechle wrote: On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the

Re: -mm merge plans for 2.6.21

2007-02-11 Thread Ralf Baechle
On Sun, Feb 11, 2007 at 04:33:41PM +0100, David Woodhouse wrote: On Sat, 2007-02-10 at 21:34 +, Ralf Baechle wrote: Unfortunately struct epoll_event contains a gap so it bets on identical padding rules between native and compat ABI and anyway, padding is wasted space so the struct

Re: -mm merge plans for 2.6.21

2007-02-11 Thread Ralf Baechle
On Sun, Feb 11, 2007 at 05:14:46PM +0100, Heiko Carstens wrote: Hmm.. so you don't need to do some fancy compat conversion for the sigset_t that gets passed? Why is that? I don't get it... Ah, I finally get your point. Yes, that needs conversion. Ralf - To unsubscribe from this list: send

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Davide Libenzi
On Sat, 10 Feb 2007, Ralf Baechle wrote: > Unfortunately struct epoll_event contains a gap so it bets on identical > padding rules between native and compat ABI and anyway, padding is wasted > space so the struct members should have been swapped when this structure > was created. Oh well, too

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Ralf Baechle
On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > > Which remembers me that I think that MIPS is using the non-compat version > > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > > syscall

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Ralf Baechle
On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: > Which remembers me that I think that MIPS is using the non-compat version > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > syscall for some reason. Dunno. Which reminds me that x86_64 i386 compat

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Dave Jones
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote: > > I'm getting fed up of holding onto hundreds of patches against subsystem > trees, sending them over and over again seeing and nothing happen. I sent > 242 > patches out to subsystem maintainers on Monday and look at what's

Re: -mm merge plans for 2.6.21 -- md-dm-reduce-stack-usage-with-stacked-block-devices.patch

2007-02-10 Thread Alasdair G Kergon
On Sat, Feb 10, 2007 at 10:58:58AM +0100, Heiko Carstens wrote: > Alasdair, is dm already fixed or is there any chance that it will > ever get fixed? I still expect us to get this changed within the next few months. We've dealt with the changes necessary to the crypt target for this. The final

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Robert Hancock
Frederik Deweerdt wrote: How about this one instead then: Well, the warning you get is not that obvious: test.c: In function 'main': test.c:11: warning: 'deprecated_irqf' is deprecated And as far as I could test (gcc 4.1.1 and gcc 3.4.3), Arjan's comment is not true, the "static const int"

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Andi Kleen
On Saturday 10 February 2007 14:48, Alan wrote: > > Well it's a technical issue -- it conflicts with the machine check > > code that is already implemented by stealing away its events. > > You would first need a CONFIG_MCE=n on x86-64 at least, otherwise > > one of them will be unhappy. > > That

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Alan
> Well it's a technical issue -- it conflicts with the machine check > code that is already implemented by stealing away its events. > You would first need a CONFIG_MCE=n on x86-64 at least, otherwise > one of them will be unhappy. That is a fair point, albeit after far too long sitting stuck in

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Frederik Deweerdt
On Sat, Feb 10, 2007 at 12:42:41PM +0100, Arnd Bergmann wrote: > On Friday 09 February 2007 12:24, Arjan van de Ven wrote: > > > > On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: > > > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; > > > +static const int __deprecated

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Andi Kleen
Alan <[EMAIL PROTECTED]> writes: > Please just push the EDAC K8 stuff. Andi will say "no" from now until the > end of time, but end users want it, distributions want it, and Andi is > not the EDAC maintainer so should consider himself overruled on what > isn't a technical issue but a personal

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Andi Kleen
David Woodhouse <[EMAIL PROTECTED]> writes: > On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: > > lutimesat-simplify-utime2.patch > > lutimesat-extend-do_utimes-with-flags.patch > > lutimesat-actual-syscall-and-wire-up-on-i386.patch > > > > Do we want this? Ulrich says so. Will merge,

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Arnd Bergmann
On Friday 09 February 2007 12:24, Arjan van de Ven wrote: > > On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: > > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; > > +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; > > +static const int __deprecated

Re: -mm merge plans for 2.6.21

2007-02-10 Thread David Woodhouse
On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > Which remembers me that I think that MIPS is using the non-compat version > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > syscall for some reason. Dunno. It's OK as long as the 64-bit kernel, N32 and O32

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Heiko Carstens
On Fri, Feb 09, 2007 at 02:50:12PM -0800, Davide Libenzi wrote: > On Fri, 9 Feb 2007, David Woodhouse wrote: > > > On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote: > > > > I would strongly recommend that in the general case, you don't merge new > > > > system calls unless the corresponding

Re: -mm merge plans for 2.6.21 -- md-dm-reduce-stack-usage-with-stacked-block-devices.patch

2007-02-10 Thread Heiko Carstens
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote: > drivers-mdc-use-array_size-macro-when-appropriate.patch > md-dm-reduce-stack-usage-with-stacked-block-devices.patch > > -> neilb > > (The second one is getting idiotic. When are we going to fix this??) Since it was me who

Re: -mm merge plans for 2.6.21 -- md-dm-reduce-stack-usage-with-stacked-block-devices.patch

2007-02-10 Thread Alasdair G Kergon
On Sat, Feb 10, 2007 at 10:58:58AM +0100, Heiko Carstens wrote: Alasdair, is dm already fixed or is there any chance that it will ever get fixed? I still expect us to get this changed within the next few months. We've dealt with the changes necessary to the crypt target for this. The final

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Dave Jones
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote: I'm getting fed up of holding onto hundreds of patches against subsystem trees, sending them over and over again seeing and nothing happen. I sent 242 patches out to subsystem maintainers on Monday and look at what's still

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Ralf Baechle
On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. Which reminds me that x86_64 i386 compat

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Ralf Baechle
On Sat, Feb 10, 2007 at 10:32:07AM +, David Woodhouse wrote: On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Davide Libenzi
On Sat, 10 Feb 2007, Ralf Baechle wrote: Unfortunately struct epoll_event contains a gap so it bets on identical padding rules between native and compat ABI and anyway, padding is wasted space so the struct members should have been swapped when this structure was created. Oh well, too late.

Re: -mm merge plans for 2.6.21 -- md-dm-reduce-stack-usage-with-stacked-block-devices.patch

2007-02-10 Thread Heiko Carstens
On Thu, Feb 08, 2007 at 03:07:10PM -0800, Andrew Morton wrote: drivers-mdc-use-array_size-macro-when-appropriate.patch md-dm-reduce-stack-usage-with-stacked-block-devices.patch - neilb (The second one is getting idiotic. When are we going to fix this??) Since it was me who asked to

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Heiko Carstens
On Fri, Feb 09, 2007 at 02:50:12PM -0800, Davide Libenzi wrote: On Fri, 9 Feb 2007, David Woodhouse wrote: On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote: I would strongly recommend that in the general case, you don't merge new system calls unless the corresponding compat_

Re: -mm merge plans for 2.6.21

2007-02-10 Thread David Woodhouse
On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. It's OK as long as the 64-bit kernel, N32 and O32

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Arnd Bergmann
On Friday 09 February 2007 12:24, Arjan van de Ven wrote: On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; +static const int __deprecated SA_SHIRQ

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Andi Kleen
David Woodhouse [EMAIL PROTECTED] writes: On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: lutimesat-simplify-utime2.patch lutimesat-extend-do_utimes-with-flags.patch lutimesat-actual-syscall-and-wire-up-on-i386.patch Do we want this? Ulrich says so. Will merge, I guess.

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Andi Kleen
Alan [EMAIL PROTECTED] writes: Please just push the EDAC K8 stuff. Andi will say no from now until the end of time, but end users want it, distributions want it, and Andi is not the EDAC maintainer so should consider himself overruled on what isn't a technical issue but a personal political

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Frederik Deweerdt
On Sat, Feb 10, 2007 at 12:42:41PM +0100, Arnd Bergmann wrote: On Friday 09 February 2007 12:24, Arjan van de Ven wrote: On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; +static const int __deprecated

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Alan
Well it's a technical issue -- it conflicts with the machine check code that is already implemented by stealing away its events. You would first need a CONFIG_MCE=n on x86-64 at least, otherwise one of them will be unhappy. That is a fair point, albeit after far too long sitting stuck in the

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Andi Kleen
On Saturday 10 February 2007 14:48, Alan wrote: Well it's a technical issue -- it conflicts with the machine check code that is already implemented by stealing away its events. You would first need a CONFIG_MCE=n on x86-64 at least, otherwise one of them will be unhappy. That is a fair

Re: -mm merge plans for 2.6.21

2007-02-10 Thread Robert Hancock
Frederik Deweerdt wrote: How about this one instead then: Well, the warning you get is not that obvious: test.c: In function 'main': test.c:11: warning: 'deprecated_irqf' is deprecated And as far as I could test (gcc 4.1.1 and gcc 3.4.3), Arjan's comment is not true, the static const int

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Oleg Verych
> From: Russell King > Newsgroups: gmane.linux.kernel > Subject: Re: -mm merge plans for 2.6.21 > Date: Fri, 9 Feb 2007 22:03:27 + [] > However: > > sys_foo(int a, int c, unsigned long long b, unsigned long long d) > > is entirely reasonable and leaves us with sp

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Andrew Morton
On Sat, 10 Feb 2007 02:15:11 +0100 Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > On Fri, 9 Feb 2007 19:37:53 + > > Alan <[EMAIL PROTECTED]> wrote: > > > >> Please just push the EDAC K8 stuff. > > > > OK. > > > >> Andi will say "no" from now until the > >> end

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Carl-Daniel Hailfinger
Andrew Morton wrote: > On Fri, 9 Feb 2007 19:37:53 + > Alan <[EMAIL PROTECTED]> wrote: > >> Please just push the EDAC K8 stuff. > > OK. > >> Andi will say "no" from now until the >> end of time, but end users want it, distributions want it, and Andi is >> not the EDAC maintainer so should

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Davide Libenzi
On Fri, 9 Feb 2007, David Woodhouse wrote: > On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote: > > > I would strongly recommend that in the general case, you don't merge new > > > system calls unless the corresponding compat_ system call is > > > implemented. > > > > Good point. > > It's

Re: -mm merge plans for 2.6.21

2007-02-09 Thread David Woodhouse
On Fri, 2007-02-09 at 22:12 +, David Woodhouse wrote: > > We could _also_ do with a way to warn about unimplemented syscalls on > any given architecture. I'm thinking about something along the lines > of > a kernel/syscalls.c containing nothing but... > > #include > >

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Guillaume Chazarain
Andrew Morton a écrit : factor-outstanding-i-o-error-handling.patch factor-outstanding-i-o-error-handling-tidy.patch I still like them. But the original problem is still present. sync_sb_inodes-propagate-errors.patch You explained in http://lkml.org/lkml/2007/1/2/238 that the mapping

Re: -mm merge plans for 2.6.21

2007-02-09 Thread David Woodhouse
On Fri, 2007-02-09 at 22:03 +, Russell King wrote: > > Is that actually written anywhere, and does anyone bother to check? > > Mostly mailing list archives I'd guess. As far as anyone bothering > to check, that's me when I'm aware of new syscalls... which typically > happens a long time

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Russell King
On Fri, Feb 09, 2007 at 02:00:49PM -0800, Andrew Morton wrote: > +asmlinkage long sys_lio_submit(aio_context_t ctx_id, int mode, long nr, > + struct iocb __user * __user *iocbpp, struct sigevent __user *event) Not a problem. (r0 := ctx_id, r1 := mode, r2 := nr, r3 := iocbpp, r4 := event)

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Russell King
On Fri, Feb 09, 2007 at 09:53:19PM +, David Woodhouse wrote: > On Fri, 2007-02-09 at 21:49 +, Russell King wrote: > > urgh, new system calls... wonder if they fit in the ARM ABI... Looks > > fine. > > Can you elucidate on _what_ you just checked for? > > There was something about

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Andrew Morton
On Fri, 9 Feb 2007 21:49:44 + Russell King <[EMAIL PROTECTED]> wrote: > On Fri, Feb 09, 2007 at 01:45:16PM -0800, Andrew Morton wrote: > > On Fri, 09 Feb 2007 17:35:35 + > > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > > > On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: > > >

Re: -mm merge plans for 2.6.21

2007-02-09 Thread David Woodhouse
On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote: > > I would strongly recommend that in the general case, you don't merge new > > system calls unless the corresponding compat_ system call is > > implemented. > > Good point. It's a _damn_ good point, but I see we went ahead and merged

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Andrew Morton
On Fri, 9 Feb 2007 19:37:53 + Alan <[EMAIL PROTECTED]> wrote: > Please just push the EDAC K8 stuff. OK. > Andi will say "no" from now until the > end of time, but end users want it, distributions want it, and Andi is > not the EDAC maintainer so should consider himself overruled on what >

Re: -mm merge plans for 2.6.21

2007-02-09 Thread David Woodhouse
On Fri, 2007-02-09 at 21:49 +, Russell King wrote: > urgh, new system calls... wonder if they fit in the ARM ABI... Looks > fine. Can you elucidate on _what_ you just checked for? There was something about alignment of 64-bit arguments to syscalls which affects MIPS and/or ARM which I can't

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Russell King
On Fri, Feb 09, 2007 at 01:45:16PM -0800, Andrew Morton wrote: > On Fri, 09 Feb 2007 17:35:35 + > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: > > > lutimesat-simplify-utime2.patch > > > lutimesat-extend-do_utimes-with-flags.patch >

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Andrew Morton
On Fri, 09 Feb 2007 17:35:35 + David Woodhouse <[EMAIL PROTECTED]> wrote: > On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: > > lutimesat-simplify-utime2.patch > > lutimesat-extend-do_utimes-with-flags.patch > > lutimesat-actual-syscall-and-wire-up-on-i386.patch > > > > Do we want

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Alan
Please just push the EDAC K8 stuff. Andi will say "no" from now until the end of time, but end users want it, distributions want it, and Andi is not the EDAC maintainer so should consider himself overruled on what isn't a technical issue but a personal political viewpoint. Alan - To unsubscribe

Re: -mm merge plans for 2.6.21

2007-02-09 Thread David Woodhouse
On Thu, 2007-02-08 at 15:07 -0800, Andrew Morton wrote: > lutimesat-simplify-utime2.patch > lutimesat-extend-do_utimes-with-flags.patch > lutimesat-actual-syscall-and-wire-up-on-i386.patch > > Do we want this? Ulrich says so. Will merge, I guess. I would strongly recommend that in the general

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Thomas Gleixner
On Thu, 2007-02-08 at 15:44 -0800, Andrew Morton wrote: > Yeah, this seems to work. > > +#define emit_old_interrupt_name(old, new)\ > +static inline unsigned __deprecated emit_old_interrupt_name##old(void) > \ > +{

Re: -mm merge plans for 2.6.21

2007-02-09 Thread deweerdt
Quoting Arjan van de Ven <[EMAIL PROTECTED]>: > > > > > As long as nobody takes the address of them (which wouldn't compile today > > anyway) then the compiler should be able to not allocate store for these. > > That they're const might help too. > > are you really sure? I've run some tests, and

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Lenar Lõhmus
Andrew Morton wrote: On Fri, 09 Feb 2007 11:54:29 +0200 Lenar Lõhmus <[EMAIL PROTECTED]> wrote: Has it? I don't think I've ever observed any benefits from it and I don't think anyone has ever got down and worked out what its drawbacks might be, and seen if they can be demonstrated in practice.

Re: -mm merge plans for 2.6.21

2007-02-09 Thread James
On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Fri, 09 Feb 2007 11:54:29 +0200 Lenar Lõhmus <[EMAIL PROTECTED]> wrote: > Hello, > > Andrew Morton wrote: > > sched-add-above-background-load-function.patch > > mm-implement-swap-prefetching.patch > >

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Arjan van de Ven
> > As long as nobody takes the address of them (which wouldn't compile today > anyway) then the compiler should be able to not allocate store for these. > That they're const might help too. are you really sure? > > > why not just bite the bullet? > > removing version.h also broke the same

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Jan Engelhardt
On Feb 9 2007 14:04, Andi Kleen wrote: >Andrew Morton <[EMAIL PROTECTED]> writes: >> >> As long as nobody takes the address of them (which wouldn't compile today >> anyway) then the compiler should be able to not allocate store for these. > >This would only work for unit-at-a-time compilers (if

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Andi Kleen
Andrew Morton <[EMAIL PROTECTED]> writes: > > As long as nobody takes the address of them (which wouldn't compile today > anyway) then the compiler should be able to not allocate store for these. This would only work for unit-at-a-time compilers (if it works at all, i'm not sure), but not older

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Andrew Morton
On Fri, 09 Feb 2007 12:24:33 +0100 Arjan van de Ven <[EMAIL PROTECTED]> wrote: > On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: > > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; > > +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; > > +static const

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Arjan van de Ven
On Fri, 2007-02-09 at 10:57 +, Frederik Deweerdt wrote: > +static const int __deprecated SA_INTERRUPT = IRQF_DISABLED; > +static const int __deprecated SA_SAMPLE_RANDOM = IRQF_SAMPLE_RANDOM; > +static const int __deprecated SA_SHIRQ = IRQF_SHARED; > +static const int __deprecated SA_PROBEIRQ =

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Frederik Deweerdt
On Fri, Feb 09, 2007 at 12:29:06AM +0100, Jan Engelhardt wrote: > > On Feb 8 2007 15:07, Andrew Morton wrote: > > >scheduled-removal-of-sa_xxx-interrupt-flags-fixups.patch > >scheduled-removal-of-sa_xxx-interrupt-flags-fixups-2.patch > >scheduled-removal-of-sa_xxx-interrupt-flags.patch >

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Andrew Morton
On Fri, 09 Feb 2007 11:54:29 +0200 Lenar Lõhmus <[EMAIL PROTECTED]> wrote: > Hello, > > Andrew Morton wrote: > > sched-add-above-background-load-function.patch > > mm-implement-swap-prefetching.patch > > mm-implement-swap-prefetching-vs-zvc-stuff.patch > >

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Sébastien Dugué
On Fri, 9 Feb 2007 01:05:57 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Fri, 9 Feb 2007 09:26:11 +0100 Sébastien Dugué <[EMAIL PROTECTED]> wrote: > > > On Fri, 9 Feb 2007 11:02:28 +0530 "Bharata B Rao" <[EMAIL PROTECTED]> wrote: > > > > > Andrew, > > > > > > On 2/9/07, Andrew Morton

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Lenar Lõhmus
Hello, Andrew Morton wrote: sched-add-above-background-load-function.patch mm-implement-swap-prefetching.patch mm-implement-swap-prefetching-vs-zvc-stuff.patch mm-implement-swap-prefetching-vs-zvc-stuff-2.patch mm-implement-swap-prefetching-use-ctl_unnumbered.patch

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Andrew Morton
On Fri, 9 Feb 2007 09:26:11 +0100 Sébastien Dugué <[EMAIL PROTECTED]> wrote: > On Fri, 9 Feb 2007 11:02:28 +0530 "Bharata B Rao" <[EMAIL PROTECTED]> wrote: > > > Andrew, > > > > On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > >

Re: -mm merge plans for 2.6.21

2007-02-09 Thread Sébastien Dugué
On Fri, 9 Feb 2007 11:02:28 +0530 "Bharata B Rao" <[EMAIL PROTECTED]> wrote: > Andrew, > > On 2/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine.patch > > fsaio-add-a-wait-queue-arg-to-the-wait_bit-action-routine-gfs2-fix.patch > >

  1   2   >