> 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?
freebsd-emulation@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org"