From owner-freebsd-current@FreeBSD.ORG Sat Aug 26 07:27:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AB5C16A4DD; Sat, 26 Aug 2006 07:27:20 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BABE43D45; Sat, 26 Aug 2006 07:27:18 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k7Q7RCoL055366 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 26 Aug 2006 09:27:12 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k7Q7R9Eh055363; Sat, 26 Aug 2006 09:27:09 +0200 (CEST) Date: Sat, 26 Aug 2006 09:27:09 +0200 From: Divacky Roman To: Intron is my alias on the Internet Message-ID: <20060826072709.GA55105@stud.fit.vutbr.cz> References: <20060825084755.GA93151@stud.fit.vutbr.cz> <20060825133034.jglu4yf9j400sosw@netchild.homeip.net> <20060825181029.GA15247@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: Problems of New Linuxulator I Have Known X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 07:27:20 -0000 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