Date: Fri, 16 Mar 2007 13:26:58 +0100 From: Divacky Roman <xdivac02@stud.fit.vutbr.cz> To: Alexander Leidinger <Alexander@leidinger.net> Cc: emulation@freebsd.org, rdivacky@freebsd.org, kib@freebsd.org, jkim@freebsd.org Subject: Re: 2.6.16 for linuxulator & 7.0 release Message-ID: <20070316122658.GA31977@stud.fit.vutbr.cz> In-Reply-To: <20070316120038.2iizia24mc4wcw8s@webmail.leidinger.net> References: <20070316120038.2iizia24mc4wcw8s@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070316122658.GA31977>