RE: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

RE: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Luck, Tony]

> 2. There is a whole range of syscalls missing for ia64 that I basically
>   interpolated from elsewhere.

I've been thinking of dropping CONFIG_IA32_SUPPORT completely from ia64.
I've heard no complaints that new syscalls are not being added to the
ia32 compat side ... which is an indication that people are not
actively using this.  Some OSDs have been building with this
turned off for a while now (perhaps in preparation for "Montecito"
which no longer has h/w support for the x86 instruction set, or
perhaps because it represnts a huge block of lightly/barely tested
code that will have its share of support issues).

I suppose I should do this by adding an entry to
 Documentation/feature-removal-schedule.txt

Any thoughts on the timeline for this?  Is Dec 31, 2006 too soon?
(or not soon enough!?).

-Tony

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Andrew Morton]

"Luck, Tony" <tony.luck@intel.com> wrote:
>
> > 2. There is a whole range of syscalls missing for ia64 that I basically
> >   interpolated from elsewhere.
> 
> I've been thinking of dropping CONFIG_IA32_SUPPORT completely from ia64.
> I've heard no complaints that new syscalls are not being added to the
> ia32 compat side ... which is an indication that people are not
> actively using this.  Some OSDs have been building with this
> turned off for a while now (perhaps in preparation for "Montecito"
> which no longer has h/w support for the x86 instruction set, or
> perhaps because it represnts a huge block of lightly/barely tested
> code that will have its share of support issues).
> 
> I suppose I should do this by adding an entry to
>  Documentation/feature-removal-schedule.txt

I don't think people actively look in there.  You'd also need to do
something like mark it CONFIG_BROKEN, which will wake people up and might
make them go look to see what happened.  Updating the now-BROKEN help text
would make that nice and easy for them.

> Any thoughts on the timeline for this?  Is Dec 31, 2006 too soon?
> (or not soon enough!?).

You'd know better than we..

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

RE: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Christoph Lameter]

On Wed, 24 May 2006, Luck, Tony wrote:

> Any thoughts on the timeline for this?  Is Dec 31, 2006 too soon?
> (or not soon enough!?).

If it does not work then remove it now. Are there any users left?

I vaguely remember some BIOS code having to be executed in ia32 mode in 
order to make some device drives work?

If that is the case then we cannot drop ia32 support at all.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Bjorn Helgaas]

On Wednesday 24 May 2006 12:45, Luck, Tony wrote:
> I've been thinking of dropping CONFIG_IA32_SUPPORT completely from ia64.
> I've heard no complaints that new syscalls are not being added to the
> ia32 compat side ... which is an indication that people are not
> actively using this.

Or maybe the people using ia32 compatibility are just running big
apps like Firefox or Open Office that are non-trivial to build for
ia64, but may not care as much about shiny new syscalls.

Later, Tony wrote:
> > Are there any users left?
> I've no idea.  Two OSDs have been shipping the Intel s/w emulator for
> a while now, one installs it by default.  So the number of users is
> probably diminishing.  When people upgrade to Montecito, s/w emulation
> is the only option, which will further reduce the user population.

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
alternative.

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.

Bjorn

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Matt Taggart]

Bjorn Helgaas writes...

> 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.

Debian is looking at implementing "multiarch", a way to have libraries
for multiple binary targets install in the same system root.

  http://wiki.debian.org/multiarch

After amd64 systems, ia64 can benefit the most from multiarch. It would
be a shame to see this not happen.

I also agree with Bjorn that the propriatary tool shouldn't be the only
way. To the Intel people on the lists that work on this, what is Intel's
position on open sourcing this technology?

Thanks,

-- 
Matt Taggart
taggart@debian.org

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Andi Kleen]

> 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
> alternative.
> 
> 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.

-Andi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

RE: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Luck, Tony]

> If it does not work then remove it now.
It still works ... it just isn't complete as most of the syscalls
added in the past 18 months haven't been included.

> Are there any users left?
I've no idea.  Two OSDs have been shipping the Intel s/w emulator for
a while now, one installs it by default.  So the number of users is
probably diminishing.  When people upgrade to Montecito, s/w emulation
is the only option, which will further reduce the user population.

> I vaguely remember some BIOS code having to be executed in ia32 mode in 
> order to make some device drives work?
> If that is the case then we cannot drop ia32 support at all.
The kernel doesn't handle BIOS code execution ... so the value of
CONFIG_IA32_SUPPORT makes no difference to this.

-Tony

If this thread continues, I'll drop all the innocent bystanders from
the Cc: list and just leave linux-ia64 from future replies.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[0/5] sys_move_pages() updates

[Christoph Lameter]

These patches are against 2.6.17-rc4-mm3 and complete
the implementation of sys_move_pages().

1. Fix brokenness in follow_page introduced with the dirty pages patch.

2. Extract common permissions check

3. Fixups sys_move_pages()

4. x86_64 support

5. 32 bit support for i386, x86_64 and ia64.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Christoph Lameter]

sys_move_pages() support for 32bit (i386 plus ia64 and x86_64 compat layers)

Add support for move_pages() on i386 and also add the
compat functions necessary to run 32 bit binaries on x86_64 and ia64.

Add compat_sys_move_pages to both the x86_64 and the ia64 32bit binary
layer. Note that both are not up to date so I added the missing pieces.
Not sure if this is done the right way.

This probably needs some fixups:

1. What about sys_vmsplice on x86_64?

2. There is a whole range of syscalls missing for ia64 that I basically
   interpolated from elsewhere.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.17-rc4-mm3/arch/i386/kernel/syscall_table.S
===================================================================
--- linux-2.6.17-rc4-mm3.orig/arch/i386/kernel/syscall_table.S	2006-05-11 16:31:53.000000000 -0700
+++ linux-2.6.17-rc4-mm3/arch/i386/kernel/syscall_table.S	2006-05-23 10:15:43.789358191 -0700
@@ -315,3 +315,5 @@ ENTRY(sys_call_table)
 	.long sys_splice
 	.long sys_sync_file_range
 	.long sys_tee			/* 315 */
+	.long sys_ni_syscall		/* vmsplice */
+	.long sys_move_pages
Index: linux-2.6.17-rc4-mm3/arch/x86_64/ia32/ia32entry.S
===================================================================
--- linux-2.6.17-rc4-mm3.orig/arch/x86_64/ia32/ia32entry.S	2006-05-22 18:03:26.298716900 -0700
+++ linux-2.6.17-rc4-mm3/arch/x86_64/ia32/ia32entry.S	2006-05-23 10:15:43.791311196 -0700
@@ -699,4 +699,5 @@ ia32_sys_call_table:
 	.quad sys_sync_file_range
 	.quad sys_tee
 	.quad compat_sys_vmsplice
+	.quad compat_sys_move_pages
 ia32_syscall_end:		
Index: linux-2.6.17-rc4-mm3/include/asm-i386/unistd.h
===================================================================
--- linux-2.6.17-rc4-mm3.orig/include/asm-i386/unistd.h	2006-05-22 18:03:30.090473603 -0700
+++ linux-2.6.17-rc4-mm3/include/asm-i386/unistd.h	2006-05-23 10:15:43.792287698 -0700
@@ -322,10 +322,11 @@
 #define __NR_sync_file_range	314
 #define __NR_tee		315
 #define __NR_vmsplice		316
+#define __NR_move_pages		317
 
 #ifdef __KERNEL__
 
-#define NR_syscalls 317
+#define NR_syscalls 318
 
 /*
  * user-visible error numbers are in the range -1 - -128: see
Index: linux-2.6.17-rc4-mm3/kernel/compat.c
===================================================================
--- linux-2.6.17-rc4-mm3.orig/kernel/compat.c	2006-05-11 16:31:53.000000000 -0700
+++ linux-2.6.17-rc4-mm3/kernel/compat.c	2006-05-23 10:15:43.793264200 -0700
@@ -21,6 +21,7 @@
 #include <linux/unistd.h>
 #include <linux/security.h>
 #include <linux/timex.h>
+#include <linux/migrate.h>
 
 #include <asm/uaccess.h>
 
@@ -934,3 +935,25 @@ asmlinkage long compat_sys_adjtimex(stru
 
 	return ret;
 }
+
+#ifdef CONFIG_NUMA
+asmlinkage long compat_sys_move_pages(pid_t pid, unsigned long nr_pages,
+		void __user *pages32,
+		const int __user *nodes,
+		int __user *status,
+		int flags)
+{
+	const void __user * __user *pages;
+	int i;
+
+	pages = compat_alloc_user_space(nr_pages * sizeof(void *));
+	for (i = 0; i < nr_pages; i++) {
+		compat_uptr_t p;
+
+		if (get_user(p, (compat_uptr_t *)(pages32 + i)) ||
+			put_user(compat_ptr(p), pages + i))
+			return -EFAULT;
+	}
+	return sys_move_pages(pid, nr_pages, pages, nodes, status, flags);
+}
+#endif
Index: linux-2.6.17-rc4-mm3/include/linux/syscalls.h
===================================================================
--- linux-2.6.17-rc4-mm3.orig/include/linux/syscalls.h	2006-05-23 10:03:36.022956244 -0700
+++ linux-2.6.17-rc4-mm3/include/linux/syscalls.h	2006-05-23 10:15:43.794240702 -0700
@@ -520,6 +520,11 @@ asmlinkage long sys_move_pages(pid_t pid
 				const int __user *nodes,
 				int __user *status,
 				int flags);
+asmlinkage long compat_sys_move_pages(pid_t pid, unsigned long nr_page,
+				void __user *pages,
+				const int __user *nodes,
+				int __user *status,
+				int flags);
 asmlinkage long sys_mbind(unsigned long start, unsigned long len,
 				unsigned long mode,
 				unsigned long __user *nmask,
Index: linux-2.6.17-rc4-mm3/arch/ia64/ia32/ia32_entry.S
===================================================================
--- linux-2.6.17-rc4-mm3.orig/arch/ia64/ia32/ia32_entry.S	2006-05-11 16:31:53.000000000 -0700
+++ linux-2.6.17-rc4-mm3/arch/ia64/ia32/ia32_entry.S	2006-05-23 10:15:43.796193706 -0700
@@ -495,6 +495,39 @@ ia32_syscall_table:
   	data8 compat_sys_mq_getsetattr
 	data8 sys_ni_syscall		/* reserved for kexec */
 	data8 compat_sys_waitid
+	data8 sys_ni_syscall		/* 285: sys_altroot */
+	data8 sys_add_key
+	data8 sys_request_key
+	data8 sys_keyctl
+	data8 sys_ioprio_set
+	data8 sys_ioprio_get		/* 290 */
+	data8 sys_inotify_init
+	data8 sys_inotify_add_watch
+	data8 sys_inotify_rm_watch
+	data8 sys_migrate_pages
+	data8 compat_sys_openat		/* 295 */
+	data8 sys_mkdirat
+	data8 sys_mknodat
+	data8 sys_fchownat
+	data8 compat_sys_futimesat
+	data8 sys_ni_syscall		/* broken: sys_fstatat 300 */
+	data8 sys_unlinkat
+	data8 sys_renameat
+	data8 sys_linkat
+	data8 sys_symlinkat
+	data8 sys_readlinkat		/* 305 */
+	data8 sys_fchmodat
+	data8 sys_faccessat
+	data8 sys_ni_syscall		/* pselect6 */
+	data8 sys_ni_syscall		/* ppoll */
+	data8 sys_unshare               /* 310 */
+	data8 compat_sys_set_robust_list
+	data8 compat_sys_get_robust_list
+	data8 sys_splice
+	data8 sys_sync_file_range
+	data8 sys_tee			/* 315 */
+	data8 compat_sys_vmsplice
+	data8 compat_sys_move_pages
 
 	// guard against failures to increase IA32_NR_syscalls
 	.org ia32_syscall_table + 8*IA32_NR_syscalls
Index: linux-2.6.17-rc4-mm3/include/asm-ia64/ia32.h
===================================================================
--- linux-2.6.17-rc4-mm3.orig/include/asm-ia64/ia32.h	2006-05-22 18:03:30.107074135 -0700
+++ linux-2.6.17-rc4-mm3/include/asm-ia64/ia32.h	2006-05-23 10:15:43.796193706 -0700
@@ -5,7 +5,7 @@
 #include <asm/ptrace.h>
 #include <asm/signal.h>
 
-#define IA32_NR_syscalls		285	/* length of syscall table */
+#define IA32_NR_syscalls		318	/* length of syscall table */
 #define IA32_PAGE_SHIFT			12	/* 4KB pages */
 
 #ifndef __ASSEMBLY__

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Andrew Morton]

Christoph Lameter <clameter@sgi.com> wrote:
>
> sys_move_pages() support for 32bit (i386 plus ia64 and x86_64 compat layers)
> 
> Add support for move_pages() on i386 and also add the
> compat functions necessary to run 32 bit binaries on x86_64 and ia64.
> 
> Add compat_sys_move_pages to both the x86_64 and the ia64 32bit binary
> layer. Note that both are not up to date so I added the missing pieces.
> Not sure if this is done the right way.
> 
> This probably needs some fixups:
> 
> 1. What about sys_vmsplice on x86_64?
> 
> 2. There is a whole range of syscalls missing for ia64 that I basically
>    interpolated from elsewhere.

I dropped the ia64 bits - looks like that's all on death row anyway.

The omission of sys_vmsplice() from the x86 syscall table does appear to
be, umm, a glaring omission.  Jens, what's up?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Jens Axboe]

On Wed, May 24 2006, Andrew Morton wrote:
> Christoph Lameter <clameter@sgi.com> wrote:
> >
> > sys_move_pages() support for 32bit (i386 plus ia64 and x86_64 compat layers)
> > 
> > Add support for move_pages() on i386 and also add the
> > compat functions necessary to run 32 bit binaries on x86_64 and ia64.
> > 
> > Add compat_sys_move_pages to both the x86_64 and the ia64 32bit binary
> > layer. Note that both are not up to date so I added the missing pieces.
> > Not sure if this is done the right way.
> > 
> > This probably needs some fixups:
> > 
> > 1. What about sys_vmsplice on x86_64?
> > 
> > 2. There is a whole range of syscalls missing for ia64 that I basically
> >    interpolated from elsewhere.
> 
> I dropped the ia64 bits - looks like that's all on death row anyway.
> 
> The omission of sys_vmsplice() from the x86 syscall table does appear to
> be, umm, a glaring omission.  Jens, what's up?

Uhm yes...

[PATCH] Add vmsplice syscall to x86 table

Signed-off-by: Jens Axboe <axboe@suse.de>

diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index f48bef1..af56987 100644
--- a/arch/i386/kernel/syscall_table.S
+++ b/arch/i386/kernel/syscall_table.S
@@ -315,3 +315,4 @@ ENTRY(sys_call_table)
 	.long sys_splice
 	.long sys_sync_file_range
 	.long sys_tee			/* 315 */
+	.long sys_vmsplice

-- 
Jens Axboe

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>