Qemu support for PPC
Quoted 5 lines · In <[email protected]> you wrote:
Quoted 1 line · Paul Mackerras
Anyway, it's not your call.
if you look at
MAINTAINERSI'm responsible for personality handling, so maybe it actually _is_ my call?
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, and you've let the 2.4 and 2.5 personality lists get out of sync.
Qemu could hack it into all the stat, stat64, open, chmod, chown, link, rename etc. calls in the emulator, yes, but the in-kernel solution already exists and is far simpler.
Quoted 1 line
Because stuff should go into 2.5 first.
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.
Quoted 4 lines
And even if it looks trivial there's an important policy decision
here: do we want to clutter up our personality system for userspace emulators? If you look at the current list of personalities they all have kernel implementations
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.
Thanks,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 3 lines · Rusty Russell
Which simply shows that an entry in the
MAINTAINERSfile 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) 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..
Quoted 2 lines
and you've let the 2.4 and 2.5 personality
lists get out of sync.
That's what's happening if people hack last minute changes into 2.4 instead of properly going through 2.5 and the maintainer.
Quoted 3 lines
Qemu could hack it into all the stat, stat64, open, chmod, chown, link, rename etc. calls in the emulator, yes, but the in-kernel solution already exists and is far simpler.
The inkernel solution exists, and it's a bad (though valueable) hack.
Quoted 4 lines
Quoted 1 line
Because stuff should go into 2.5 first.
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.
Quoted 3 lines
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? :)
In message <[email protected]> you write:
Quoted 7 lines · Rusty Russell
Quoted 3 lines
Which simply shows that an entry in the
MAINTAINERSfile 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(
Quoted 2 lines
I now don't understand the personalities at all?
Remember that I wrote most of the code that's now inkernel/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".
Quoted 9 lines
Quoted 2 lines
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.
Quoted 11 lines
Quoted 3 lines
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_altrootmechanism that doesn't rely on the personality handling which isn't needed by qemu at all but rather just exposesset_fs_altrootto 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.
Quoted 6 lines · Rusty Russell
Oh good: a serious question. Why don't we drop the personality field in struct
task_structand just useexec_domain? Then the flags could be unfolded from the personality number, and placed in a "flags" element in structexec_domain, thepersonality()macro would vanish, theset_personality()macro would vanish, and things would be generally clearer?
The personality number is exposed through sys_personality, so unfortunately we can't get rid of it. I still wonder what crack the person inviting this scheme was smoking, though..
Quoted 3 lines
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.
You can just easily let it run in a chroot or separate namespace, you just won't get second look semantics. (Personally I think that's a benefit, but some people disagree with this).
In message <[email protected]> you write:
Quoted 11 lines · Rusty Russell
Quoted 6 lines
Oh good: a serious question. Why don't we drop the personality field in struct
task_structand just useexec_domain? Then the flags could be unfolded from the personality number, and placed in a "flags" element in structexec_domain, thepersonality()macro would vanish, theset_personality()macro would vanish, and things would be generally clearer?The personality number is exposed through
sys_personality, so unfortunately we can't get rid of it. I still wonder what crack the person inviting this scheme was smoking, though..
Yes. It's a PITA that the bottom 8 bits map to exec_domain, and the rest are random flags. If each different personality mapped to a separate exec_domain, the flags could be moved to the exec_domain struct and it'd be far more logical. But as you say, this would break userspace which expects to be able to set the exec_domain and the flags separately 8(.
BTW, there's a module refcount leak here:
int__set_personality(u_long personality)
{
struct exec_domain *ep, *oep;
ep = lookup_exec_domain(personality);
if (ep == current_thread_info()->exec_domain) {
current->personality = personality;
return 0;
}You need "module_put(ep->owner)", since lookup_exec_domain bumps the refcount.
Quoted 7 lines
Quoted 3 lines
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.
You can just easily let it run in a chroot or separate namespace, you just won't get second look semantics. (Personally I think that's a benefit, but some people disagree with this).
No, then you can't access your files, which is unacceptable for many users.
I've done the userspace implementation: I'll see if Fabrice chokes on the speed hit.
Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 2 lines · Rusty Russell
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.
If it hasn't been generally accepted and cleaned up for 2.5 then it shouldn't be going into 2.4
Quoted 3 lines
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.
WTF should that make it slow ?
In message <[email protected]> you write:
Quoted 5 lines
Quoted 3 lines
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.
WTF should that make it slow ?
Well, there are two obvious methods. The first, which I've implemented, builds a tree at start time, which assumes things stay static, but has significant startup overhead.
The fully dynamic solution (which personality + emul_prefix gives you at the moment) means that you double every open, every stat, quadruple every readlink, etc. Of course, remember to handle relative paths (my current code punts on this in the hope that noone will notice: we'll see).
Unfortunately, it's not just /lib and /usr/lib, there's /var/run/.nscd_socket which doesn't seem to like speaking wrong endian.
Hey, I'd *love* read-only union mounts which can be done by non-root (and obviously don't survive exec), but AFAICT noone but Al can write one acceptable to the VFS maintainer 8).
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.