On Mon, 19 Jul 2010 12:35:08 +0300, Antti Kantee <po...@cs.hut.fi> wrote: > On Mon Jul 12 2010 at 19:05:03 +0200, Jean-Yves Migeon wrote: >> >> My initial step would be to have a block backend driver running in >> >> userland, so I can make it run as a standalone server. Purpose is to >> >> help diagnosing errors in a more graceful manner. I lost tremendous >> >> time >> >> tracking a DoS issue between frontend and backend drivers for domain >> >> migration, for one stupid reason: the backend caused a DoS to the rest >> >> of the *dom0* kernel, without even being capable of breaking into >> >> ddb... >> > >> > Ok, now I'm confused again. If you want to make it run in dom0 >> > userspace, >> > what is your interest with the hypercall api? Or is that just the >> > initial step? I thought you wanted multiple "dom0"s. >> >> Initial step. > > Guess I forgot respond to this. What I wanted to say was that apart > from some Makefiles, I'm not sure how much your initial step and final > goal have in common implementation-wise.
Let's set the context. Backend drivers serve two main functionalities: 1 - copy/map the block/char requests from domU space to backend driver space; this rely on the Xen API (hypercalls, event channels, ring I/O). 2 - rework these requests so that they could be passed further to other layers, either vfs or network stacks. All your work makes big improvements regarding (2). I would like to see what I could do about (1). What does it have to do with my final goal: 1 and 2 are largely independant; the backend concept is shared by other microkernels architectures (not opensource in my case, though). If I manage to "virtualize" (1) (~= run the current kernel code in a POSIX userland environment) without pulling in too much code (or losing operation semantic), adding fs or network support to the environment would be, I expect, easier than porting a complete kernel to the hypervisor/microkernel API in question. -- Jean-Yves Migeon jeanyves.mig...@free.fr