From: Andi Kleen
Newer glibc did some include namespace "cleanups" and removed
struct ucontext and friends. This already broke a lot of software,
and UML seems to be the latest victim.
Use the typedefs which are still available. They also work on
older glibcs.
Signed-off-by:
On Mon, Sep 01, 2008 at 10:06:18AM -0400, Jeff Dike wrote:
> On Mon, Sep 01, 2008 at 11:32:00AM +0200, Andi Kleen wrote:
> > Steve VanDeBogart <[EMAIL PROTECTED]> writes:
> > > Kconfig option for Valgrind. Suppression file, for known non-issues.
> > > Valgrind he
Steve VanDeBogart <[EMAIL PROTECTED]> writes:
> Kconfig option for Valgrind. Suppression file, for known non-issues.
> Valgrind header files (svn 8534) that define the client request
> mechanism used to annotate programs plus a couple lines to integrate
> with Kconfig.
Couldn't you just get the
On Wed, Jan 09, 2008 at 09:14:04PM -0500, Jeff Dike wrote:
> On Wed, Jan 09, 2008 at 10:50:48PM +0100, Miklos Szeredi wrote:
> > > FASTCALL is useless and should not make a difference. It enables
> > > regparm on specific functions, but that should not make a difference
> > > if it works or not.
>
On Wed, Jan 09, 2008 at 10:20:49PM +0100, Miklos Szeredi wrote:
> > Miklos Szeredi <[EMAIL PROTECTED]> writes:
> >
> > > FASTCALL is defined empty in -mm, but UML is not compiled with
> > > -mregparm=3 and so this breaks things (I noticed problems with
> > > rwsem_down_write_failed).
> > >
> > > T
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> FASTCALL is defined empty in -mm, but UML is not compiled with
> -mregparm=3 and so this breaks things (I noticed problems with
> rwsem_down_write_failed).
>
> Tried recompiling UML with -mregparm=3, but that resulted in a strange
> failure immediately
On Tue, Oct 23, 2007 at 05:44:17PM +0200, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > [...] -pg should in theory work with -mregparms.
> >
> > last i checked it didnt work - i'll re-check that.
>
> earlier gcc versions had problems with -mregparm and with -pg. I just
On Tue, Oct 23, 2007 at 04:20:06PM +0200, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > >> You should rename it then to "asmcall" or something.
> > >
> > > if then that should be a separate renaming patch.
> >
&
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>> > so this patch adds back fastcall annotations. This serves as
>> > documentation for assembly calling-convention dependencies as well.
>>
>> You should renam
Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> the 'fastcall removal' changes to paravirt.c were over-eager: they
> removed fastcall annotations from functions that are (or might be)
> implemented in assembly. So if someone changes the compiler model,
> such as -pg which disables regparm, the kernel b
Jeff Dike <[EMAIL PROTECTED]> writes:
> [ This is both 2.6.24 and -stable material ]
>
> SuSE seems to require that binaries have a .note.SuSE section.
> Without it, UML segfaults if any parameters are passed on the command
> line.
This doesn't make any sense. You must have misanalyzed this.
-A
On Tuesday 01 May 2007 20:21:57 Jeff Dike wrote:
> Rearrange the i386 cmpxchg code to allow atomic.h to get it without
> needing to include system.h. This kills warnings in the UML build
> from atomic.h about implicit declarations of cmpxchg symbols. The
> i386 build presumably isn't seeing this
> #include
> #include
> +#include
Sorry no. system.h is the header from hell and putting it into a "basic" header
like atomic_t will likely cause all kinds of problems.
If it's a real issue move cmpxchhg into a different header and include that
from system.h and atomic.h. system.h has too mu
On Thursday 05 October 2006 23:38, Paolo 'Blaisorblade' Giarrusso wrote:
> Andi Kleen pointed out that -mcmodel=kernel does not make sense for userspace
> code and would stop everything from working,
did it work at all
Jeff Dike <[EMAIL PROTECTED]> writes:
>
> x86_64 is also treated in this way for consistency.
>
> This patch was run by linux-arch yesterday with no comment.
Well you should have sent it to me.
I think I would prefer a well placed ifdef __KERNEL__ or two for this - i don't
like it when it beco
On Tuesday 08 August 2006 16:03, Paolo Giarrusso wrote:
> Andi Kleen <[EMAIL PROTECTED]> ha scritto:
>
> > Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> writes:
> >
> > > From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTE
Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> writes:
> From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
>
> We have never used this flag and recently one user experienced a complaining
> warning about this (there was a symbol in the positive half of the address
> space
> IIRC). So
On Thursday 29 June 2006 23:36, Jeff Dike wrote:
> Andi is making pte_mkexec go away, and UML had one of the last uses.
Actually not go away, but do the correct thing on i386/x86-64.
Just relying on its side effects of setting _USER was bad.
Thanks,
-Andi
Using Tomcat but need to do more? Need t
> It isn't yet perfect, because we don't yet save floating point context. But
> that will come later. Additionally, there's a potential problem since RED
> zones will alternate stacks are used, unlike x86_64, so more stack space
> (128 bytes more) is used. But this shouldn't be a problem.
> Instea
On Monday 05 June 2006 13:06, Blaisorblade wrote:
> On Sunday 04 June 2006 21:06, Andi Kleen wrote:
> > > It isn't yet perfect, because we don't yet save floating point context.
> > > But that will come later. Additionally, there's a potential problem since
&
yscall exit tracing twice
int_ret_from_syscall already does syscall exit tracing, so
no need to do it again in the caller.
This caused problems for UML and some other special programs doing
syscall interception.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/arch/x86_
On Wednesday 26 October 2005 00:44, Blaisorblade wrote:
> For what I see, that's based on the tradeoff between space and contention -
> for instance there are few zones only, so there's no big waste.
If space is precious it shouldn't be padded at all.
> In practice, interpreting !X86_GENERIC as
> No correctness issues, obviously. So this could even be merged for 2.6.14
> (I'm not a fan of this idea, though).
I don't think it's a good idea to mess with this for 2.6.14
In general the maxaligned stuff is imho bogus and should be removed. That is
what CONFIG_X86_GENERIC is for. It doesn't
On Wednesday 26 October 2005 00:13, Paolo 'Blaisorblade' Giarrusso wrote:
>
> I.e. the implementation was written, is present in the tree, but due to
> this:
>
> #ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
> #include /* use a generic implementation */
> #else
> #include /* use an arch-specific implemen
Jeff Dike <[EMAIL PROTECTED]> writes:
> Noticed by Al Viro - SMP on x86_64 is fundamentally broken due to
> UML's reuse of the host arch's percpu stuff. This is OK on x86, but
> the x86_64 pda stuff just won't work for UML.
The generic one should work too, it's just less efficient.
So you can pr
On Sun, May 08, 2005 at 03:44:14PM +0200, Arjan van de Ven wrote:
>
> > But it has to be *really* lightweight because these transistion can
> > happen a lot (consider a CPU that very often goes to sleep for a short time)
>
> lightweight is good of course. But even if it's medium weight.. it just
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> On Sun, 2005-05-08 at 13:50 +1000, Rusty Russell wrote:
>> My preference would be the second: fix the scheduler so it doesn't rely
>> on regular polling. However, as long as the UP case runs with no timer
>> interrupts when idle, many people will be
Srivatsa Vaddagiri <[EMAIL PROTECTED]> writes:
> Hello,
> I need some inputs from the community (specifically from virtual
> machine and embedded/power-management folks) on something that I am working
> on.
I think the best way is to let other CPUs handle the load balancing
for idle CPUs.
On Sun, May 01, 2005 at 08:45:15PM +0200, [EMAIL PROTECTED] wrote:
>
> From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>
>
> These are some trivial fixes for the x86-64 subarch module support. The only
> potenti
> I agree this can be a bit kludgy, so if you want add another solution.
Patch is ok for me, but you have a good chance of having broken
other archs too due to the string.c changes. Probably needs some testing.
-Andi
---
This SF.Net email is s
30 matches
Mail list logo
