From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 20 16:50:47 2008 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 352D0106567B for ; Thu, 20 Mar 2008 16:50:47 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id E4CF78FC35 for ; Thu, 20 Mar 2008 16:50:46 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 873DF67761B; Thu, 20 Mar 2008 17:50:38 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-iTMITQC23v; Thu, 20 Mar 2008 17:50:25 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 0EB7B677725; Thu, 20 Mar 2008 17:50:25 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id m2KGoOW0083359; Thu, 20 Mar 2008 17:50:24 +0100 (CET) (envelope-from rdivacky) Date: Thu, 20 Mar 2008 17:50:24 +0100 From: Roman Divacky To: Alexander Leidinger Message-ID: <20080320165024.GA83087@freebsd.org> References: <96317980@ipt.ru> <20080319204521.GA98846@freebsd.org> <20080320080703.ws5h2vaqskkw4w0s@webmail.leidinger.net> <20080320085122.GB32936@freebsd.org> <20080320111524.0j8stbuny84gwswc@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080320111524.0j8stbuny84gwswc@webmail.leidinger.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-emulation@FreeBSD.org Subject: Re: [PATCH]: additional futex operations 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: Thu, 20 Mar 2008 16:50:47 -0000 > The thought behind this is, that we can go from "should be" to "are". > Doing a rate limited logging (print the message once) in -current (not > in a MFC) should be enough to get a better idea. > > >Also.. if anyone is willing/able to implement the FD backing I think such > >person is skilled enough to see what is the problem even without the > >printf. > > It's not about finding some to implement it, it's about getting _hard_ > facts in our userbase. what is the point in getting to know that we dont implement FD backed futexes? I already know that :) in a case of problems people should be running -DDEBUG linuxulator anyway. I dont honestly think that anyone will ever implement the FD backed futexes (too much work for basically null gain). > >It can only confuse normal people I think.. > > For this reason I said to change the comment. Here's what I mean: > ---snip--- > static int limit_once = 0; > if (!limit_once) { > limit_once = 1; > printf("FD futex not implemented, linux wants to deprecate > it. Do not report this, except when you see a real failure/misbehavior > because of this."); > } > return (ENOSYS); > ---snip--- I dont like it but I wont object if you commit it > >I'd let it be as it is > > > >>Is this a proof of concept (do you plan to make a no-op > >>LINUX_FUTEX_PRIVATE_FLAG case in the switch to be consistent) or the > >>final solution? I see pros/cons for both and I think it doesn't matter > >>how it is done, I'm just curious about your opinion. > > > >we DO implement private futexes. we DONT implement shared ones. We dont > >share futexes on "vm" structure or file descriptor. The only reason why > >it works is because 99% of application want private futexes but dont > >claim so :) > > Yes, I understand that. What I wanted to know is, if you want to add a > if/case statement with LINUX_FUTEX_PRIVATE_FLAG which does nothing > (except containing the comment) for consistency/strict correctness > reasons. As told above, I see value in both ways of doing it. I assume > now you want to commit the patch as is, no need to comment further on > this. I reworded the comment why we clear the flag.. it should be enough I think. honestly... the only case where we dont support correct futexes is when they are mapped between processes and/or mapped on an fd. I dont think that you can find such a program easily. what you can find easily otoh is PI futexes. I think I'll try to do something about it in my spare time.. that looks more interesting and useful... anyone want to join me? or fund me? ;)