Re: dropping CONFIG_IA32_SUPPORT from ia64
- To: Bjorn Helgaas <email@example.com>
- Cc: "Luck, Tony" <firstname.lastname@example.org>, "Christoph Lameter" <email@example.com>, firstname.lastname@example.org, "Hugh Dickins" <email@example.com>, firstname.lastname@example.org, "Peter Zijlstra" <email@example.com>, "Lee Schermerhorn" <firstname.lastname@example.org>, "Nick Piggin" <email@example.com>, firstname.lastname@example.org, "KAMEZAWA Hiroyuki" <email@example.com>, firstname.lastname@example.org
- Subject: Re: dropping CONFIG_IA32_SUPPORT from ia64
- From: Andi Kleen <email@example.com>
- Date: Thu, 25 May 2006 05:30:59 +0200
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <[🔎] email@example.com>
- References: <B8E391BBE9FE384DAA4C5C003888BE6F0693FC5B@scsmsx401.amr.corp.intel.com> <[🔎] firstname.lastname@example.org>
> I'm a bit worried about this. As I understand it, the Intel
> software emulator is not open-source. There may be distros
> like Debian and customer environments where that's not a viable
> If we remove CONFIG_IA32_SUPPORT, every ia64 box will require
> the Intel emulator (or QEMU or some other ill-defined solution)
> in order to run ia32 code, even though every processor in the
> field today supports ia32 in hardware.
> It doesn't feel right to me to remove functionality from machines
> in the field and offer only a proprietary alternative.
You could just freeze the code down to "security fixes only".
This means new system calls wouldn't need to be added and most programs
fallback if they don't see the latest and great syscalls anyways.
On the other hand it is usually not very hard to add new syscalls
and most of the other code is shared now anyways.