> How are kernel hackers to know it's been deprecated? ;-)
Good idea, yes.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Mon, Jan 24, 2005 at 05:00:53PM +0100, Andi Kleen wrote:
> But seriously I wouldn't bother - the syscall interface is deprecated anyways
> and has been for a long time. The only sysctl that needs to be handled
> is (CTL_KERN,KERN_VERSION) [used by glibc], the others are not needed
> and I hoep
On Tue, Jan 25, 2005 at 12:50:01AM +1100, Anton Blanchard wrote:
>
> > > Is there any reason to not move the sys32_sysctl code to kernel/sysctl.c?
> >
> > iirc it relies on a unified address space (= user pointers still
> > work in KERNEL_DS)
>
> Yeah the sys32_sysctl code is pretty awful,
> > Is there any reason to not move the sys32_sysctl code to kernel/sysctl.c?
>
> iirc it relies on a unified address space (= user pointers still
> work in KERNEL_DS)
Yeah the sys32_sysctl code is pretty awful, perhaps we could do a better
job now we have compat_alloc_userspace.
Anton
-
To
On Tue, Jan 25, 2005 at 12:50:01AM +1100, Anton Blanchard wrote:
Is there any reason to not move the sys32_sysctl code to kernel/sysctl.c?
iirc it relies on a unified address space (= user pointers still
work in KERNEL_DS)
Yeah the sys32_sysctl code is pretty awful, perhaps we
On Mon, Jan 24, 2005 at 05:00:53PM +0100, Andi Kleen wrote:
But seriously I wouldn't bother - the syscall interface is deprecated anyways
and has been for a long time. The only sysctl that needs to be handled
is (CTL_KERN,KERN_VERSION) [used by glibc], the others are not needed
and I hoep to
How are kernel hackers to know it's been deprecated? ;-)
Good idea, yes.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Is there any reason to not move the sys32_sysctl code to kernel/sysctl.c?
iirc it relies on a unified address space (= user pointers still
work in KERNEL_DS)
Yeah the sys32_sysctl code is pretty awful, perhaps we could do a better
job now we have compat_alloc_userspace.
Anton
-
To
On Sun, Jan 23, 2005 at 02:35:00PM +, Matthew Wilcox wrote:
> On Sun, Jan 23, 2005 at 04:01:02PM +1100, Anton Blanchard wrote:
> > Create a cond_syscall for sys32_sysctl and make all architectures use
> > it. Also fix the architectures that dont wrap their 32bit compat sysctl
> > code.
>
> Is
On Sun, Jan 23, 2005 at 04:01:02PM +1100, Anton Blanchard wrote:
> Create a cond_syscall for sys32_sysctl and make all architectures use
> it. Also fix the architectures that dont wrap their 32bit compat sysctl
> code.
Is there any reason to not move the sys32_sysctl code to kernel/sysctl.c?
--
On Sun, Jan 23, 2005 at 04:01:02PM +1100, Anton Blanchard wrote:
Create a cond_syscall for sys32_sysctl and make all architectures use
it. Also fix the architectures that dont wrap their 32bit compat sysctl
code.
Is there any reason to not move the sys32_sysctl code to kernel/sysctl.c?
--
On Sun, Jan 23, 2005 at 02:35:00PM +, Matthew Wilcox wrote:
On Sun, Jan 23, 2005 at 04:01:02PM +1100, Anton Blanchard wrote:
Create a cond_syscall for sys32_sysctl and make all architectures use
it. Also fix the architectures that dont wrap their 32bit compat sysctl
code.
Is there
Create a cond_syscall for sys32_sysctl and make all architectures use
it. Also fix the architectures that dont wrap their 32bit compat sysctl
code.
Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]>
diff -puN arch/ia64/ia32/sys_ia32.c~sysctl_fixup2 arch/ia64/ia32/sys_ia32.c
---
Create a cond_syscall for sys32_sysctl and make all architectures use
it. Also fix the architectures that dont wrap their 32bit compat sysctl
code.
Signed-off-by: Anton Blanchard [EMAIL PROTECTED]
diff -puN arch/ia64/ia32/sys_ia32.c~sysctl_fixup2 arch/ia64/ia32/sys_ia32.c
---
14 matches
Mail list logo
