Hi Joerg, hi folks,
On Fri, Dec 30, 2011 at 03:49:06PM +0100, Joerg Sonnenberger wrote:
On Thu, Dec 22, 2011 at 08:22:17PM +0400, Valeriy E. Ushakov wrote:
On Thu, Dec 22, 2011 at 15:31:45 +, David Holland wrote:
Consequently, the changes should be reverted, at least until the
design
On Sat, Dec 31, 2011 at 05:44:31PM +0100, Reinoud Zandijk wrote:
On Fri, Dec 30, 2011 at 03:49:06PM +0100, Joerg Sonnenberger wrote:
On Thu, Dec 22, 2011 at 08:22:17PM +0400, Valeriy E. Ushakov wrote:
On Thu, Dec 22, 2011 at 15:31:45 +, David Holland wrote:
Consequently, the
On Sat, 31 Dec 2011 17:20:16 +
David Holland dholland-t...@netbsd.org wrote:
The other obvious approach is to add one or more new ptrace operations
to provide proper/adequate/better support for intercepting system
calls. This is probably a more useful facility in the long run, and it
On Sat, Dec 31, 2011 at 05:20:16PM +, David Holland wrote:
The other obvious approach is to add one or more new ptrace operations
to provide proper/adequate/better support for intercepting system
calls. This is probably a more useful facility in the long run, and it
*can* be made
On Thu, Dec 22, 2011 at 08:22:17PM +0400, Valeriy E. Ushakov wrote:
On Thu, Dec 22, 2011 at 15:31:45 +, David Holland wrote:
Consequently, the changes should be reverted, at least until the
design has been gone through carefully.
Seconded.
Nothing happened yet?
Joerg
Le 22/12/11 18:00, Thor Lancelot Simon a écrit :
[snip]
Anyway, that's just one possible alternate approach. Working through it
makes me really wonder whether there's _any_ portable way to do this stuff.
But I wish we could have a public discussion about it before hacking up
public interfaces
On Sun, Dec 25, 2011 at 02:44:13AM +0100, Jean-Yves Migeon wrote:
Le 22/12/11 18:00, Thor Lancelot Simon a ?crit :
What does usermode Linux do?
It seems they implemented new syscalls (and a specific PTRACE hook)
in the host to allow execution of syscalls in another context, see
On Wed, Dec 21, 2011 at 16:47:49 +0100, Reinoud Zandijk wrote:
From the beginning of the usermode project, we struggled with the
fact that system calls in usermode's userland will go to the wrong
kernel [...]
Because you chose to run userland code in the same process with the
usermode kernel
On Thu, Dec 22, 2011 at 08:22:17PM +0400, Valeriy E. Ushakov wrote:
On Wed, Dec 21, 2011 at 16:47:49 +0100, Reinoud Zandijk wrote:
From the beginning of the usermode project, we struggled with the
fact that system calls in usermode's userland will go to the wrong
kernel [...]
Because
This all seems simple and elegant enough, but it does not (quite) work:
A) It still requires a new system call on the outer kernel.
*Perhaps* this could be avoided by using ptrace, which might
be simpler with this approach because the rule is simple:
just say
On Thu, Dec 22, 2011 at 03:46:34PM -0500, Mouse wrote:
ptrace can support this too. It can let sbrk/mmap through, but tell
the usermode kernel as it does so. Or it can consult with the usermode
kernel first, and then let them through in a possibly modified form.
I still don't see how this
In article 20111223013511.ga10...@panix.com,
Thor Lancelot Simon t...@panix.com wrote:
On Thu, Dec 22, 2011 at 03:46:34PM -0500, Mouse wrote:
ptrace can support this too. It can let sbrk/mmap through, but tell
the usermode kernel as it does so. Or it can consult with the usermode
kernel
On Thu, Dec 22, 2011 at 09:23:54PM -0500, Mouse wrote:
...making them appear asynchronously with respect to userland
userspace's calls to userland kernel would, yes, be difficult. (Or
anything else that lets the ptracer regain control; syscalls are just
the most convenient such thing.)
13 matches
Mail list logo
