From owner-freebsd-emulation@FreeBSD.ORG Fri Mar 16 12:41:54 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0990C16A402 for ; Fri, 16 Mar 2007 12:41:54 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id A275613C43E for ; Fri, 16 Mar 2007 12:41:53 +0000 (UTC) (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.8/8.13.7) with ESMTP id l2GCQw0c033132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Mar 2007 13:26:58 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l2GCQwG2033131; Fri, 16 Mar 2007 13:26:58 +0100 (CET) Date: Fri, 16 Mar 2007 13:26:58 +0100 From: Divacky Roman To: Alexander Leidinger Message-ID: <20070316122658.GA31977@stud.fit.vutbr.cz> References: <20070316120038.2iizia24mc4wcw8s@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070316120038.2iizia24mc4wcw8s@webmail.leidinger.net> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org, rdivacky@freebsd.org, kib@freebsd.org, jkim@freebsd.org Subject: Re: 2.6.16 for linuxulator & 7.0 release X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 12:41:54 -0000 On Fri, Mar 16, 2007 at 12:00:38PM +0100, Alexander Leidinger wrote: > Hi, > > ATM it doesn't look like we can enable 2.6.16 by default in 7.0. The > reasons: > - java showstopper (epoll not implemented) > - futex/TLS for amd64 not in -current for testing > - futexes not completely right > - *at() not implemented > - the time to test a 2.6.16 default until 7.0 shrinks fast > > Roman has some preliminary work regarding *at() and it looks good to > him. He wants me to test some stuff but I don't have enough time in > the next weeks because of work related stuff. Any volunteers to help > out? the code looks ok and it even passes LTP tests. I hope that someone with VFS-fu will review my linux_at() function and then I'll implement all the *at syscalls. as java is regarded I think its not a big problem to patch java shell script to set emulation to 2.4 etc. but I agree that 2.6 is not ready for 7.0R there's also problem with 2.6 emulation with flash9 (eating memory till it dies) > In p4 we have the futex/TLS stuff for amd64 but because of the futexes > not completely right part it is not committed to current yet. As we > already have the futex and TLS stuff for i386 on a similar level in > current, I would say we should go ahead and sync the amd64 stuff. It > is not used by default, so we don't break existing linux stuff and we > get the benefit of more people being able to have a look at it and > play with it. So what are your opinions, shall we give jkim@ the green > light to MFp4 the futex/TLS stuff? futexes are broken... I just recieved a report that oracle installer hangs on amd64/SMP waiting on a lock. The TLS@amd64 looks good though I dont see any harm in commiting futexes/TLS for amd64 - go for it kim! I'd like to see the linux-aio commited as well before 7.0R > Regarding the futexes not being completely right and the epoll stuff: > I think it needs to be done now, not in a month or two, else we don't > have enough time to let people play with this before the release of > 7.0. Anyone with a little bit of time at hand out there? We need a > specification what the futexes are supposed to do (so far we didn't > find a good description, and the linux code is hard to read and > doesn't not really tell what it is _supposed_ to do) and we need > people which compare the current code we have with this specification. > Finding a regression test for futexes would also be nice. I plan to apply for SoC this year with a plan to implement epoll/inotify interface + "finish" the linux26 stuff... if I get elected I guess things will move forward fast :) I definitely plan to look at the futexes (we have a testing program so its not that hard) roman