2008/7/31 Olivier Thauvin <[EMAIL PROTECTED]>:
> I never notice in FAQ or documentation this limitation. Is this normal ? Is
> there any plan to remove this limitation ? Is there a technical problem to
> fix this denying to fix this ?
(Sorry for the repost, I didn't reply to all the first time.)
optraceswitchmm"
switches for good measure, as "noptracefaultinfo", "noptraceldt", and
"noprocmm" (SKAS3), and "nogetsiginfo" (SKAS4) are already available.
Signed-off-by: Ryan Finnie <[EMAIL PROTECTED]>
---
start_up.c | 44 +++
The PTRACE_GETSIGINFO notice was missing a linefeed. In addition, tab
and wrap each SKAS4 "disabled" message in parens so it doesn't break up
the indendation within the switch_mm check block.
Signed-off-by: Ryan Finnie <[EMAIL PROTECTED]>
---
start_up.c | 11 +
I just looked at what it would take to port SKAS3 to 2.6.25, and it
looks well beyond my C non-abilities. Porting 2.6.23's SKAS3 to
2.6.24 was mostly an exercise in figuring out what code from
i386/x86_64 moved to where, but 2.6.24 to 2.6.25 seems to have
reworked a lot of the ptrace/ldt code. Ho
On Tue, Apr 15, 2008 at 12:47 PM, Nix <[EMAIL PROTECTED]> wrote:
> > The problem is NTP adjusting the multiplier part of the clock-provided
> > cycles-to-ns conversion function. UML pretended to have a ns clock,
> > with a multiplier of 1. When NTP adjusted that down in order to slow
> > down
The PTRACE_GETSIGINFO notice was missing a linefeed. In addition, tab
and wrap each SKAS4 "disabled" message in parens so it doesn't break up
the indendation within the switch_mm check block.
diff -ruN linux-2.6.24.orig/arch/um/os-Linux/start_up.c
linux-2.6.24/arch/um/os-Linux/start_up.c
--- l
The SKAS4 patch that eventually hits mainline will almost certainly be
incompatible with the current working SKAS4 patchset. To that end, add
mode=skas3, so current SKAS4 guests can be run in SKAS3 mode if/when
future SKAS4 hosts are incompatible. At current time, if a SKAS4 check
fails, it f
Jeff, the SKAS4 patches are looking good so far, thanks. This,
combined with the news that Debian will be releasing an
"etch-and-a-half" supported 2.6.24 kernel, has made me start looking
at plans for 64-bit at work. At the moment there is no 32-bit object
support in x86_64 UML kernels, and of co
Oh, and it appears that with a little glue (attached), the SKAS3 and
SKAS4 patches can co-exist. I currently have a host running with both
SKAS3 and SKAS4 guests running on it. And if you apply SKAS3, SKAS4 and
the glue to a guest, it should be able to run on SKAS3 or SKAS4 hosts
(with SKAS4 bein
Ryan Finnie wrote:
> sysdep-i386/skas_ptrace.h and sysdep-x86_64/skas_ptrace.h are nearly
> identical, so I can't figure out why ptrace_faultinfo and ptrace_ldt are
> being defined in the first place.
Looks like they were added to include/asm-um/ptrace-x86_64.h to solve a
disparity
Please find attached a SKAS3 patch against Linux 2.6.24-rc7, based on
Jeff Dike's 2007-12-08 patch for 2.6.23.
Quoteth Jeff:
> 2.6.24 is going to be even more interesting, given the x86 merge.
Indeed it is. This patch is not perfect and I need some help. Host
i386 and x86_64 build with CONFIG_P
11 matches
Mail list logo
