Alle 22:16, venerd=EC 19 dicembre 2003, Ingo Molnar ha scritto:
> * BlaisorBlade <blaisorblade_spam@...> wrote:
> > > WARNING: this is an experimental patch, UML kernels compiled with this
> > > patch wont work in skas mode on older host-skas patched kernels.
You mean that they won't work on 2.4 SKAS kernels or on 2.6 skas kernels=20
without your change(i.e. there have been some other ports of Skas to 2.5/2.=
which didn't touch the actual code logic)? If I've understood you correctly=
you must just re-add the MM_COPY_SEGMENTS call in the UML arch, while still=
making its implementation in the i386 arch as a no-op, to make us happy.=20
Right? Could you do this?
> > Does this warning refers to any of the other patches you posted? To
> > which one especially? Is this related to the removal of
> > MM_COPY_SEGMENTS ?
> yes, it refers mostly to the removal of MM_COPY_SEGMENTS.
> > Also, if there is any incompatibility, it should be named skas4. But
> > since Jeff Dike's will release skas4, even improving skas3 by breaking
> > compatibility is not useful. And if it is accepted, it should at least
> > be released also for 2.4(the guest 2.4/2.6 choice must be unrelated to
> > the host choice).
> skas4 will be nice, and since it will most likely be 2.6 based (?), it
> doesnt have the copy_segments problem.
The patch is very useful, but I think that at least the MM_COPY_SEGMENTS=20
change should be split out, since it is not backward compatible. Anything=20
required to fix a bug can be put inside, but preserving it. So preserve=20
binary compatibility with old host-skas kernels and old guest kernels.
Jeff has already refused patches for skas3(a cleanup actually, the one of=20
renaming do_mmap_pgoff as __do_mmap_pgoff as I said you), which hadn't got=
any problem, just because he wants to release skas4.
Such a speedup could be useful maybe for skas4, but only maybe(i.e. since=20
skas4 will have to be for 2.4 also, I think that MM_COPY_SEGMENTS can be ma=
a no-op, but the guest must call it).
In fact, I think he planned skas 4 for 2.4; he said also it is almost ready=
just has some problems with the two new syscall numbers. And UML developmen=
is still mainly on 2.4; fixes are applied currently on 2.4 tree, and at som=
moment will appear on the 2.6 one.
However, the one to refer to for such issues is actually Jeff Dike; this is=
only my VERY HUMBLE opinion; I'm answering just because I've been lurking o=
the ML's from enough time to understand the Jeff's plans.
> Jeff, do you know how the new skas4 syscall API will look like, exactly?
He mentioned that /proc/mm will be removed, and there will be two new=20
syscalls: one will be to create a new address space, and the second will be=
to use a certain context(i.e. a certain mm_struct) for any syscall from the=
guest to the host(I am not able to find his message, so this is what I=20
remember). This design was agreed on by Jeff and Linus.
Btw: some changes in your patch are just build-generated files(headers, and=
symlinks in the arch/um/sys-i386 dir). Pay attention to making clean(or=20
mrproper) next time before creating the patch. If you get some error from=20
"sh" about SIZE and shell arithmetic, it's already fixed(in a thread from a=
few days ago).
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729