Alle 05:00, gioved=EC 19 agosto 2004, Jeff Dike ha scritto:
> I've released a second 2.6.7 UML patch. This is to push out the changes I
> have in order to give me a clean slate for the 188.8.131.52 UML.
About the patch (and even the 184.108.40.206-1 one), there are two problems:
* First, please do a "make clean" before releasing the patch. There are som=
binaries included in it! And also semaphore.c, which is a symlink normally.
* Second, why do you disable module support when compiling it, or anyhow ho=
could you succeed to build it? Starting from this patch (this bug is not=20
there in 2.6.7-1, and remains in 220.127.116.11-1) we have this line twice:
So it did not compile for me (I patched it, obviously). Patch attached -=20
Also, you must still export a tons of symbols, plus make hostfs depend on=20
externfs. Also, to avoid linking against libgcc_s.so and exporting some of=
its symbols, which change, I made use of do_div for 64-bit division. For=20
this, see uml-export-Symbols.patch. It's only for 2.6 - for 2.4 it's a bit=
more complex (a module export all its symbols in 2.4, but if you link=20
statically the code you must export the symbol by hand inside an EXPORT_OBJ=
and if you export a missing symbol you get a link time failure).
Btw, about the ->statfs op: you are missing some unsigned-ness for some=20
params, since sector_t, used in kstatfs, is unsigned. Do you want them fixe=
* About filehandle_switch: you deleted a line (probably by mistake). Reread=
more carefully the separate patches you get with quilt: when you see the=20
other attached patch (uml-restore-lost-code.patch), you'll agree with me.
Also, what you say about the patch is not correct: filehandle_switch has=20
almost just a cosmetic effect (there is a change from os_open_file to=20
open_file for new_mm mode, and nothing else). I've attached the 2.4.26-2 pa=
which is more actually the filehandle_switch part (it's not a perfect one, =
contains some unrelated changes, but anyway you can fix it).
However, IMHO, since you cannot close and reopen a pipe, it's braindead tha=
the switch_pipe array is an array of filehandles. You must obviously use=
the make_pipe() API to call reclaim_fds() if needed, but making it return=20
filehandles is useless. They are never added onto the list, also, so they=20
never become reclaimable. But about the filehandle abstraction, I have a lo=
of doubts, for which I'll write a separate mail. I like the idea, but not t=
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729