Date: Thu, 20 Mar 2008 17:50:24 +0100 From: Roman Divacky <rdivacky@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-emulation@FreeBSD.org Subject: Re: [PATCH]: additional futex operations Message-ID: <20080320165024.GA83087@freebsd.org> In-Reply-To: <20080320111524.0j8stbuny84gwswc@webmail.leidinger.net> References: <96317980@ipt.ru> <20080319204521.GA98846@freebsd.org> <20080320080703.ws5h2vaqskkw4w0s@webmail.leidinger.net> <20080320085122.GB32936@freebsd.org> <20080320111524.0j8stbuny84gwswc@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? ;)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080320165024.GA83087>