Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled.
Signed-off-by: Jeff Dike <[email protected]>
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...) \
Jeff Dike <[email protected]> wrote:
>
> Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled.
>
> Signed-off-by: Jeff Dike <[email protected]>
>
> 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?
On Wed, Jan 04, 2006 at 03:24:33PM -0800, Andrew Morton wrote:
> Jeff Dike <[email protected]> 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
>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
--
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
>> >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
--
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
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 <[email protected]> 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 <[email protected]>
--- 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)
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 <[email protected]>
Great. Now, how do you simultaneously implement
If MODE_SKAS=n, MODE_TT must be y.
Jeff
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 <[email protected]>
>
> 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
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.
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
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
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 <[email protected]>
>> 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
--
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
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.