Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH] Qemu support for PPC | Date | Mon, 07 Apr 2003 18:34:17 +1000 |
| |
In message <20030407075622.A28354@infradead.org> you write: > On Mon, Apr 07, 2003 at 04:45:33PM +1000, Rusty Russell wrote: > > Which simply shows that an entry in the MAINTAINERS file does not a > > maintainer make, since your first post showed such misundestanding of > > what personalities do, > > oha, just because I read the patch wrongly (I somehow though it added > a binary format)
You didn't read the patch, but you said it was a bad idea. Do you wonder why people don't send patches through you? 8(
> I now don't understand the personalities at all? > Remember that I wrote most of the code that's now in kernel/exec_domain.c..
Oh good: a serious question. Why don't we drop the personality field in struct task_struct and just use exec_domain? Then the flags could be unfolded from the personality number, and placed in a "flags" element in struct exec_domain, the personality() macro would vanish, the set_personality() macro would vanish, and things would be generally clearer?
Perhaps there's some future aim you have in mind which conflicts with this, or is it just a "not done yet".
> > I happens, though, whatever you may think. It was done as a 2.4 patch > > because there's a tighter time constraint on entry into 2.4. > > Umm, quemu exists for about two weeks now. I think you're pressing > a bit too much. > > Why is there a time constraint? It worked for you up to now without > this patch in mainline and you can keep patching your trees for 2.4.21, > too.
That applies to any kernel mod, of course. qemu is much more usable (ie. it's sanely packagable) with this functionality, ie. it's pretty much a requirement for increasing adoption.
> > This is not qemu specific, of course. If you say it's not going in, > > then I'll accept that and do the work inside qemu. It'll be damn > > slow, of course. > > Please try it in userspace first, if it's really not doable we can abuse > the kernel for it, but I'd prefer not doing it. And if we need to do > it in the kernel we should think about a sys_altroot mechanism that doesn't > rely on the personality handling which isn't needed by qemu at all but > rather just exposes set_fs_altroot to userspace directly. In fact that > sounds like a very good idea to start with. What about hacking it up > for 2.5? :)
I discussed this with Paul M, too. You can do it *iff* you drop it on exec, otherwise you get chroot-like security issues.
Cheers, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |