Re: Problems of New Linuxulator I Have Known

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
CLONE_STOPPED
CLONE_VFORK
CLONE_SYSVSEM

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

>  
>> 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

>> 3. wakeup_one(9) instead of wakeup(9) should be used for futex(2) to
>>    wake up a single sleeping thread.
> 
> yes... I agree
> 
>> 4. Some options of clock_gettime(2) actually can be implemented, though
>>    FreeBSD native implementation is different from Linux's.
> 
> I might look at it
> 
>> 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.

> 
>> In a word, may ORACLE 10g for Linux be able to run under FreeBSD soon.
> 
> nice :)

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.

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

------------------------------------------------------------------------
                                                From Beijing, China