RE: + perfmon2-reserve-system-calls.patch added to -mm tree

From: Luck, Tony (tony.luck_at_intel.com)
Date: 11/15/05

  • Next message: Johannes Stezenbach: "Re: [linux-dvb-maintainer] Re: [OOPS] Linux 2.6.14.2 and DVB USB"
    Date:	Tue, 15 Nov 2005 07:28:35 -0800
    To: "Andi Kleen" <ak@muc.de>, "Arjan van de Ven" <arjan@infradead.org>
    
    

    >> ... which is a binary only, proprietary application.
    >
    >The IA32 emulation part of it is actually shipped in source.
    >Somehow they manage to link a binary only object to it though.

    There are two parts to the ia32 emulation ... the part that handles
    all the Linux syscall emulation is open (LGPL I think). The part
    that handles translation of x86 instructions into ia64 instructions
    is the binary only part ... a shared library that gets attached by
    the Linux layer ... this same binary blob is used on all operating
    systems.

    >> Either way, either the emulation is in the kernel or it's not. If it's
    >> there (like it is now) it deserves maintenance. If it's not, it should
    >> be removed from the tree, since the only thing it's otherwise good for
    >> is potential security holes.
    >
    >I suppose it's still useful for all current IA64 users (Montecito
    >is not shipping yet and older CPUs support x86 in hardware) who don't like
    >binary only software.

    I was planning on asking who still depends on the emulation code
    a while after Montecito is shipping. Until then I'll try to do
    what makes sense in keeping the ia32 emulation system call table
    up to date.

    The perfmon syscalls would be an example of something that should
    *NOT* go into the ia32 emulation syscall table. It makes no sense
    whatever to put them there. I don't believe that the h/w emulation
    provides any performance counter emulation, and even if it did a
    user who cared about the performance of their application would do
    far better to re-compile it as native ia64 than to mess around
    trying to optimize their x86 binary.

    -Tony
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Johannes Stezenbach: "Re: [linux-dvb-maintainer] Re: [OOPS] Linux 2.6.14.2 and DVB USB"

    Relevant Pages

    • Re: [Fastboot] Re: [announce] kexec for linux 2.6.6
      ... > For the momen the only finished port is x86, ... I don't want to use this in glibc for every syscall. ... to the userlevel code. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] Add FUTEX_CMP_REQUEUE futex op
      ... Is it safe to go adding a new argument to an existing syscall in this manner? ... It'll work OK on x86 because of the stack layout but is the same true of ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: + perfmon2-reserve-system-calls.patch added to -mm tree
      ... The IA32 emulation part of it is actually shipped in source. ... Somehow they manage to link a binary only object to it though. ... I suppose it's still useful for all current IA64 users (Montecito ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] 2.4 force_successful_syscall()
      ... From David's description of the 2.5 patch (the link above has ... use a syscall convention which provides for a return value and a separate ... On x86, this would be ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [PATCH][2.6.9-mm1] perfctr x86-64 ia32 emulation fix
      ... The perfctr syscall numbers changed in the i386 kernel ... but the x86-64 kernel's ia32 emulation was not ... This patch fixes that. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)