Stian, can you please read this and provide some help? The point of interest for you is ***MARKED***
On Friday 11 February 2005 01:31, Rob Landley wrote: > On Thursday 10 February 2005 10:44 am, Blaisorblade wrote: > > > And requiring SKAS mode to use uclibc > > > > uclibc doesn't allow static linking? It's strange... > > Sorry, meant UML. > (I have a cold.) Best wishes for your health... (please, someone translate this to real English :-) ) > > > Any idea when SKAS0 might be ready for testing? > > > > You can already test it I guess, but probably it's not for production > > yet. > > > > I (Wildly) guess a month could be enough, maybe... however for now you > > can do some testing in SKAS mode (the setup inside UML is not different). > > So if I build 2.6.11-rc3-bk? I can fire up SKAS0 mode and run it on an > unmodified kernel? If so, I'm happy to test this... (I read Jeff Dike's > blog entry on SKAS0, but it didn't really have any implementation details.) Well, code already exists. Get the appropriate -mm tree and apply on top of it the "incrementals" tree at http://user-mode-linux.sourceforge.net/patches.html. Give a quick read to the changelogs to get a feeling about what's actually needed and what won't at all compile. I guess that in this moment skas0-ldt is a good point to stop at. > > > is roughly equivalent to requiring a > > > kernel module in order to work. > > Ok, are you able to figure out a way to copy the whole binary (+ libs) to > > the VM file and remap it from the file to arbitrary address spaces? > Not with this cold and without a lot more study of how UML works, Yes, obviously... actually, I also have made some confusion (I actually answered to "why UML in TT mode is built static?", not to the bug in TT mode). ***MARKED*** The bug in TT mode: actually, it happens when and because UML is statically linked, against NPTL glibc. It does not happen on normal distros, which provide a LinuxThreads glibc in /lib and for static linking to be 2.4 compatible; nor in Gentoo with nptl disabled (which was the default when I installed it). The problem, currently, is that there are problems (and linker assertion failures) probably because the linking scripts do not play well with the /usr/lib/libc.a sections. The error, if I recall it correctly, is posted in the comment #6. Linking scripts give instructions about how to merge / order symbols of various sections inside the final binary; more info is provided in the info pages for ld. Uml's linking script are a mix of arch/i386/kernel/vmlinux.lds.S (which contains special kernels definition, used for instance for initcalls) and of the normal linking scripts used to build userspace executables (they are visible in the output of "strings ld", and maybe there is even some special option). To dissect binary and library sections, objdump is also useful (and also the elfutils version of it). Now, I don't understand why that error is born - it guesses wrongly the number of physical headers, and I could describe in detail the physical headers I want (each physical header groups a number of sections with similar mapping requirements). ***MARKED*** Stuff below refers to "Why UML in TT mode is built static?" > but first > I want to confirm that you looked at the new 2.6 nonlinear mappings support > (mm/fremap.c, sys_remap_file_pages() and friends...) Hmm, I know that feature, only I don't understand how it could help *here*... basically, I think everything that you can do through remap_file_pages() can be done through mmap() / munmap() / mremap(), and the advantage is only for performance... and since the mappings in this case are created So, when and if there will be a remap_file_pages where you can also change protections and we'll drop all the mmap() we must create (one mmap for each page is not very nice... in fact with >=256 M of RAM for single process inside UML you must increase the max number of mappings a single process can create). Having 65536 mappings, put together inside a red-black tree, is not nice at all. > > This is why in TT mode UML is statically linked, it's done so that we > > must not understand where libraries are located and remap them, too. I > > don't think there is a clean way (other than parsing /proc/self/maps, but > > that is a horrible kludge). > > Is there a post somewhere describing the problem in more detail? No idea, if it exists, (about why UML is statically linked) it is older than me here (and I follow UML only since 1 year and a half). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
