From: Jeff D. <jd...@ad...> - 2006-01-04 20:59:42
|
Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled. Signed-off-by: Jeff Dike <jd...@ad...> 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...) \ |
From: Andrew M. <ak...@os...> - 2006-01-04 23:22:42
|
Jeff Dike <jd...@ad...> wrote: > > Produce a compile-time error if both MODE_SKAS and MODE_TT are disabled. > > Signed-off-by: Jeff Dike <jd...@ad...> > > 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? |
From: Jan E. <je...@li...> - 2006-01-05 07:45:42
|
>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 -- |
From: Jeff D. <jd...@ad...> - 2006-01-05 15:22:32
|
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 |
From: Jan E. <je...@li...> - 2006-01-05 22:00:12
|
>> >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 -- |
From: Jeff D. <jd...@ad...> - 2006-01-06 00:01:34
|
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 |
From: Rob L. <ro...@la...> - 2006-01-07 00:01:49
|
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. |
From: Jeff D. <jd...@ad...> - 2006-01-07 01:45:11
|
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 |
From: Jan E. <je...@li...> - 2006-01-07 15:13:06
|
>> 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 -- |
From: Jeff D. <jd...@ad...> - 2006-01-07 22:25:18
|
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 |
From: Rob L. <ro...@la...> - 2006-01-08 03:50:37
|
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. |