[PATCH 4/9] UML - Better diagnostics for broken configs

[PATCH 4/9] UML - Better diagnostics for broken configs

[Jeff Dike]

Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled.

Signed-off-by: Jeff Dike <jdike@addtoit.com>

Index: linux-2.6.15/arch/um/include/choose-mode.h
===================================================================
--- linux-2.6.15.orig/arch/um/include/choose-mode.h	2005-08-28 19:41:01.000000000 -0400
+++ linux-2.6.15/arch/um/include/choose-mode.h	2005-11-17 10:43:47.000000000 -0500
@@ -23,6 +23,9 @@ static inline void *__choose_mode(void *
 
 #elif defined(UML_CONFIG_MODE_TT)
 #define CHOOSE_MODE(tt, skas) (tt)
+
+#else
+#error CONFIG_MODE_SKAS and CONFIG_MODE_TT are both disabled
 #endif
 
 #define CHOOSE_MODE_PROC(tt, skas, args...) \

Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Andrew Morton]

Jeff Dike <jdike@addtoit.com> wrote:
>
> Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled.
> 
> Signed-off-by: Jeff Dike <jdike@addtoit.com>
> 
> Index: linux-2.6.15/arch/um/include/choose-mode.h
> ===================================================================
> --- linux-2.6.15.orig/arch/um/include/choose-mode.h	2005-08-28 19:41:01.000000000 -0400
> +++ linux-2.6.15/arch/um/include/choose-mode.h	2005-11-17 10:43:47.000000000 -0500
> @@ -23,6 +23,9 @@ static inline void *__choose_mode(void *
>  
>  #elif defined(UML_CONFIG_MODE_TT)
>  #define CHOOSE_MODE(tt, skas) (tt)
> +
> +#else
> +#error CONFIG_MODE_SKAS and CONFIG_MODE_TT are both disabled
>  #endif
>  
>  #define CHOOSE_MODE_PROC(tt, skas, args...) \

Is there no sane way to prevent this situation within Kconfig?

Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Jeff Dike]

On Wed, Jan 04, 2006 at 03:24:33PM -0800, Andrew Morton wrote:
> Jeff Dike <jdike@addtoit.com> wrote:
> >
> > Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled.
> Is there no sane way to prevent this situation within Kconfig?

I tried.  The best I managed was to get *config to moan about circular
dependencies.

				Jeff

[2.6 patch] UML - Prevent MODE_SKAS=n and MODE_TT=n

[Adrian Bunk]

On Wed, Jan 04, 2006 at 09:21:29PM -0500, Jeff Dike wrote:
> On Wed, Jan 04, 2006 at 03:24:33PM -0800, Andrew Morton wrote:
> > Jeff Dike <jdike@addtoit.com> wrote:
> > >
> > > Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled.
> > Is there no sane way to prevent this situation within Kconfig?
> 
> I tried.  The best I managed was to get *config to moan about circular
> dependencies.

The patch below implements this in Kconfig.

> 				Jeff

cu
Adrian


<--  snip  -->


If MODE_TT=n, MODE_SKAS must be y.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-git/arch/um/Kconfig.old	2006-01-06 13:41:02.000000000 +0100
+++ linux-git/arch/um/Kconfig	2006-01-06 13:41:14.000000000 +0100
@@ -83,7 +83,7 @@
         of physical memory.
 
 config MODE_SKAS
-	bool "Separate Kernel Address Space support"
+	bool "Separate Kernel Address Space support" if MODE_TT
 	default y
 	help
 	This option controls whether skas (separate kernel address space)

Re: [2.6 patch] UML - Prevent MODE_SKAS=n and MODE_TT=n

[Jeff Dike]

On Fri, Jan 06, 2006 at 01:44:38PM +0100, Adrian Bunk wrote:
> If MODE_TT=n, MODE_SKAS must be y.
> 
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>

Great.  Now, how do you simultaneously implement 
	If MODE_SKAS=n, MODE_TT must be y.

				Jeff

Re: [2.6 patch] UML - Prevent MODE_SKAS=n and MODE_TT=n

[Adrian Bunk]

On Fri, Jan 06, 2006 at 11:39:48AM -0500, Jeff Dike wrote:
> On Fri, Jan 06, 2006 at 01:44:38PM +0100, Adrian Bunk wrote:
> > If MODE_TT=n, MODE_SKAS must be y.
> > 
> > 
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> Great.  Now, how do you simultaneously implement 
> 	If MODE_SKAS=n, MODE_TT must be y.

That is already implemented in my patch:

MODE_TT=n forces MODE_SKAS=y.
MODE_TT=y allows any setting of MODE_SKAS.

MODE_SKAS=n is therefore impossible if MODE_TT=n.

> 				Jeff

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] UML - Prevent MODE_SKAS=n and MODE_TT=n

[Jeff Dike]

On Fri, Jan 06, 2006 at 05:18:31PM +0100, Adrian Bunk wrote:
> That is already implemented in my patch:
> 
> MODE_TT=n forces MODE_SKAS=y.
> MODE_TT=y allows any setting of MODE_SKAS.
> 
> MODE_SKAS=n is therefore impossible if MODE_TT=n.

Right you are.

		Jeff

Re: [2.6 patch] UML - Prevent MODE_SKAS=n and MODE_TT=n

[Jeff Dike]

On Fri, Jan 06, 2006 at 01:44:38PM +0100, Adrian Bunk wrote:
> > I tried.  The best I managed was to get *config to moan about circular
> > dependencies.
> 
> The patch below implements this in Kconfig.

Acked-by: Jeff Dike <jdike@addtoit.com>

Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Jan Engelhardt]

>Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled.
>
What would happen if both were disabled?
Say, if the host system does not have SKAS and I did not want any 
tracing/debugging stuff?



Jan Engelhardt
-- 

Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Jeff Dike]

On Thu, Jan 05, 2006 at 08:45:36AM +0100, Jan Engelhardt wrote:
> >Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled.
>
> What would happen if both were disabled?
> Say, if the host system does not have SKAS and I did not want any 
> tracing/debugging stuff?

You get a UML that can't run.  TT mode isn't tracing/debugging stuff.  It's 
a basic mode of UML operation.  Also, UML doesn't need the skas patch on
the host in order to use skas mode any more.  It helps, but is not necessary.

				Jeff

Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Jan Engelhardt]

>> >Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled.
>>
>> What would happen if both were disabled?
>> Say, if the host system does not have SKAS and I did not want any 
>> tracing/debugging stuff?
>
>You get a UML that can't run.  TT mode isn't tracing/debugging stuff.  It's 
>a basic mode of UML operation.  Also, UML doesn't need the skas patch on
>the host in order to use skas mode any more.  It helps, but is not necessary.

config MODE_TT
        bool "Tracing thread support"
        default y
        help
        This option controls whether tracing thread support is compiled
        into UML.  Normally, this should be set to Y.  If you intend to
        use only skas mode (and the host has the skas patch applied to it),
        then it is OK to say N here.

Then I unfortunately do not quite understand what this is for.



Jan Engelhardt
-- 

Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Jeff Dike]

On Thu, Jan 05, 2006 at 10:59:58PM +0100, Jan Engelhardt wrote:
> config MODE_TT
>         bool "Tracing thread support"
>         default y
>         help
>         This option controls whether tracing thread support is compiled
>         into UML.  Normally, this should be set to Y.  If you intend to
>         use only skas mode (and the host has the skas patch applied to it),
>         then it is OK to say N here.
> 
> Then I unfortunately do not quite understand what this is for.

The help is a bit out of date, that's all.

				Jeff

Re: [uml-devel] Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Rob Landley]

On Thursday 05 January 2006 15:59, Jan Engelhardt wrote:
> config MODE_TT
>         bool "Tracing thread support"
>         default y
>         help
>         This option controls whether tracing thread support is compiled
>         into UML.  Normally, this should be set to Y.  If you intend to
>         use only skas mode (and the host has the skas patch applied to it),
>         then it is OK to say N here.
>
> Then I unfortunately do not quite understand what this is for.

User Mode Linux works a bit like gdb: it uses ptrace to intercept the system 
calls a process makes and handles them itself instead of allowing the 
underlying OS to do so.

Unfortunately, stock kernels don't let you just discard a system call, so you 
have to pass _something_ on to the underlying OS before you can resume from 
the ptrace.  But you can change all the information both on the way in and on 
the way out, so what UML did was it turned all system calls into "getpid", 
which it then ignored the return value of in favor of doing its own system 
call handling.  Stock kernels also don't allow one process to remap another 
process's memory, which is kind of important in context switching and meant 
that each process being traced had to be a separate PID on the host, because 
the UML kernel couldn't remap that process's page tables.

Doing both of these things (a seperate host process for each UML process, and 
calling getpid() for all system calls), is what "Tracing Thread" mode did.  
The UML kernel was one thread among several, and it was kinda slow.

Then the UML guys started patching the kernel, adding the ability to not pass 
on a system call (to eliminate the pointless calls to getpid() that just 
served to throw in a lot of context switches and slow everything down a 
suprising amount), and adding /proc/mm to let one process remap another's 
memory.  This was "SKAS" mode (Single Kernel Address Space), and was much 
faster but required a modified host kernel.  They went through a few 
iterations of this (different host patches) until they came up with the 
current version, "SKAS3".  (Of course if you're going to run a modified host 
kernel, you might as well just use XEN.)

Then somebody got drunk and came up with something extremely clever that I'm 
_still_ trying to get a clear explanation of, but they found out a way to run 
SKAS mode on an unmodified kernel by sacrificing a chicken or something, and 
this became known as "SKAS0" mode.  It's not as fast as SKAS3 mode 
(sacrificing chickens takes time), but it's faster than TT mode and a lot 
less cluttered because you don't need a separate process on the host for each 
process running under User Mode Linux kernel. 

Both TT and SKAS0 run on unmodified kernels.  I ignore SKAS3 entirely, because 
it doesn't.

SKAS0 works pretty well now, it's faster and less complicated than TT mode, 
and thus TT mode is mostly obsolete now.  If you compile UML and run SKAS, 
it'll auto-detect if your host kernel has the weird patches to support the 
extensions for SKAS3, and if not it'll run SKAS0.  TT mode is mostly an 
anachronism, except that they haven't made SKAS0 support SMP yet, so if you 
want to emulate SMP via UML you have no choice but to use TT mode (not that 
it necessarily works all that great there, since TT mode doesn't get much 
testing anymore).

> Jan Engelhardt

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

Re: [uml-devel] Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Jeff Dike]

On Fri, Jan 06, 2006 at 06:01:13PM -0600, Rob Landley wrote:
> Unfortunately, stock kernels don't let you just discard a system call, so you
> have to pass _something_ on to the underlying OS before you can resume from 
> the ptrace.  But you can change all the information both on the way in and on
> the way out, so what UML did was it turned all system calls into "getpid", 
> which it then ignored the return value of in favor of doing its own system 
> call handling.  Stock kernels also don't allow one process to remap another 
> process's memory, which is kind of important in context switching and meant 
> that each process being traced had to be a separate PID on the host, because 
> the UML kernel couldn't remap that process's page tables.
> 
> Doing both of these things (a seperate host process for each UML process, and
> calling getpid() for all system calls), is what "Tracing Thread" mode did.  
> The UML kernel was one thread among several, and it was kinda slow.

The skas vs tt distinction is the address space part of this.  How we nullify
system calls is separate.  That's the PTRACE_SYSCALL vs PTRACE_SYSEMU (which
is now in mainline) thing.

> Then somebody got drunk and came up with something extremely clever that I'm 
> _still_ trying to get a clear explanation of, but they found out a way to run
> SKAS mode on an unmodified kernel by sacrificing a chicken or something, and 
> this became known as "SKAS0" mode.  

Hehe, that would be Blaisorblade - I've refrained from asking what he had
to sacrifice.

> It's not as fast as SKAS3 mode 
> (sacrificing chickens takes time), but it's faster than TT mode and a lot 
> less cluttered because you don't need a separate process on the host for each
> process running under User Mode Linux kernel. 

skas0 still requires one host process per UML process.  That's how it gets
host address spaces, which skas3 does using /proc/mm.  In this sense, skas0
is sort of a cross between tt and skas3 modes.

				Jeff

Re: [uml-devel] Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Jan Engelhardt]

>> Doing both of these things (a seperate host process for each UML process, and
>> calling getpid() for all system calls), is what "Tracing Thread" mode did.  
>> The UML kernel was one thread among several, and it was kinda slow.
>
>The skas vs tt distinction is the address space part of this.  How we nullify
>system calls is separate.  That's the PTRACE_SYSCALL vs PTRACE_SYSEMU (which
>is now in mainline) thing.
>

...
So there is no way to get UML compile on non-Linux.


Jan Engelhardt
-- 

Re: [uml-devel] Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Jeff Dike]

On Sat, Jan 07, 2006 at 04:12:50PM +0100, Jan Engelhardt wrote:
> So there is no way to get UML compile on non-Linux.

Umm, no.  We're describing how it works on Linux.  That doesn't mean it
only can work on Linux.

The libc-dependent code movement which has been going into mainline is part
of making UML use VT (Intel hardware virtualization support), where the
runtime environment is different enough that it makes sense to handle this
as a port to a new OS.

There was also a nearly complete Windows port a few years ago which has
bitrotted since.

				Jeff

Re: [uml-devel] Re: [PATCH 4/9] UML - Better diagnostics for broken configs

[Rob Landley]

On Saturday 07 January 2006 09:12, Jan Engelhardt wrote:
> >The skas vs tt distinction is the address space part of this.  How we
> > nullify system calls is separate.  That's the PTRACE_SYSCALL vs
> > PTRACE_SYSEMU (which is now in mainline) thing.
>
> ...
> So there is no way to get UML compile on non-Linux.

Not out of the box, no.  You need some equivalent debugging facility, but 
that's not too high a barrier.  It's really that there's no way for a 
userspace process to fiddle around with the MMU the way an OS wants to, 
unless you A) put hooks in the OS, or B) have multiple processes with 
different memory contexts, which means debugging hooks if you want one thread 
to intercept the syscalls made by another thread.

There have been occasional attempts at doing this, by the way.  (If I had 
gotten a mac mini I was going to give it a try, but about two _hours_ before 
I had scheduled an extra long lunch hour to go visit the Apple store in the 
barton creek mall, I heard about Jobs' announcement of the switchover to 
Intel processors, so I didn't.  Not like I really _need_ another todo item 
that's going to wind up taking up six months of my free time.  Just use 
qemu...)

> Jan Engelhardt

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.