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
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,
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.
-- 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 email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/