> 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
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
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
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
> 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:
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
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
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
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.
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
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
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
--- 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
> 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
> 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
>
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
...
--- 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
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-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-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
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
--- 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
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
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
--- 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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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
> 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
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
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
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,
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
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
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
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
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
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
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
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
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.
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
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_
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
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
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.
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
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
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
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
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
> 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
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
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
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
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
>
>
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
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
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)
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
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:
> > >
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
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
>
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
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
>
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
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
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
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)
> \
> +{
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
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.
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
> >
>
> 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
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
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
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
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 =
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
>
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
> >
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
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
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:
> > >
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 - 100 of 154 matches
Mail list logo