Re: Problems of New Linuxulator I Have Known

On Sat, Aug 26, 2006 at 11:16:23AM +0800, Intron is my alias on the Internet wrote:
> Divacky Roman wrote:
> 
> >On Fri, Aug 25, 2006 at 11:14:44PM +0800, Intron is my alias on the 
> >Internet wrote:
> >>1. Many options of clone(2) are not correctly implemented, some of
> >>   which may cause application crash when it wants to clone
> >>   memory-independent process.
> > 
> >like?
> 
> CLONE_FS

this one is only for kernel threads. I doubt we will ever support linux kernel
threads :)

> CLONE_STOPPED

this should be very easy to add, I didnt see any use of that so I didnt implement
that so far, but it should be very easy

> CLONE_VFORK

I tend to believe this is used only for vfork() implementation but if not this is
also quite trivial to implement (take a look at my linux_vfork() implementation)

> CLONE_SYSVSEM

this might be a bit trickier because I know nothing about sysvsem, but judging
from the code its not a big thing

> Implementation of CLONE_PTRACE and CLONE_UNTRACED can be delayed,
> though they are useful, too.

I am getting panics when trying to use linux-strace, this is worth investigating

> > 
> >>2. TLS (Thread Local Storage) support in clone(2), set_thread_area(2)
> >>   and get_thread_area(2) doesn't conform to Linux 2.6.x, which can
> >>   damage stack of Linux application using NPTL (Native  POSIX  Threads
> >>   Library).
> >>
> >>   Of course, to obtain the conformation, FreeBSD native GDT must be
> >>   rearranged. But Linux NPTL is quite essential for modern Linux
> >>   applications.
> >
> >what do you mean that doesnt conform? TLS in linux is implemented using
> >GDT. the only difference between fbsd and linux I can think of is that
> >linux supports 3 gdt entries while fbsd just one.
> >
> 
> Linux hardcodes TLS entry number ranging from 6 to 8 for i386, or from
> 12 to 14 for amd64. But FreeBSD allows only entry number 3. I'm afraid
> Linux application checks entry number by macros GDT_ENTRY_TLS_MIN and
> GDT_ENTRY_TLS_MAX to judge whether the calling is successful.
> In GNU/Linux distribution, these two macros are defined in
> /usr/include/asm/segment.h, and in Linux kernel source the file is
> linux-2.6.17.11/include/asm-i386/segment.h or
> linux-2.6.17.11/include/asm-x86_64/segment.h

I've never seen an app that would check this. Also this thing should be setup
by threading library and we can easily check it there. I dont think this is a real
problem. The glibc doesnt check this (it just uses whatever we supply it) and there
should be no other user.

> >>3. wakeup_one(9) instead of wakeup(9) should be used for futex(2) to
> >>   wake up a single sleeping thread.
> >
> >yes... I agree

I plan to do this once everything else is resolved because I really want to shrink
the gap between my p4/uncommited linuxolator and what is in src.

> >>5. Code style problems: member naming of structure, macro naming,
> >>   function naming, encapsulation for queue(3) and so on.
> >
> >in my code or in the imported code?
> 
> Most of them are in NetBSD code.

this is imported code and we want it to stay the same to easy possible future imports.
if you found something bad in my code pls tell me (I'd prefer icq)

> So far, Linuxulator is quite undependable. Kernel panic arises from time
> to time. In this case, shaky running of ORACLE 10g is meaningless.
> We have to continue our effects.

pls, can you share the panics with me?

> Can you publicize your testing programs for those Linux system calls?

I am sure this is of your interest: www.stud.fit.vutbr.cz/~xdivac02/futex.c

we dont pass this even with your patches

thnx for your work!

roman