public inbox for linux-api@vger.kernel.org
 help / color / mirror / Atom feed
From: Elizabeth Figura <zfigura@codeweavers.com>
To: Andy Lutomirski <luto@kernel.org>,
	wine-devel@winehq.org, Arnd Bergmann <arnd@arndb.de>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	"André Almeida" <andrealmeid@igalia.com>,
	"Wolfram Sang" <wsa@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Alexandre Julliard" <julliard@winehq.org>
Subject: Re: [RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device.
Date: Thu, 25 Jan 2024 12:21:59 -0600	[thread overview]
Message-ID: <3785748.kQq0lBPeGt@terabithia> (raw)
In-Reply-To: <63b3828d-8482-4435-9c98-50578bbbbe07@app.fastmail.com>

On Thursday, 25 January 2024 10:47:49 CST Arnd Bergmann wrote:
> On Thu, Jan 25, 2024, at 04:42, Elizabeth Figura wrote:
> > On Wednesday, 24 January 2024 16:56:23 CST Elizabeth Figura wrote:
> >> On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote:
> >> > On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura 
<zfigura@codeweavers.com> wrote:
> >> [There is also a potential problem where some broken applications
> >> create a million (literally) sync objects. Making these into files runs
> >> into NOFILE. We did specifically push distributions and systemd to
> >> increase those limits because an older solution *did* use eventfds and
> >> *did* run into those limits. Since that push was successful I don't
> >> know if this is *actually* a concern anymore, but avoiding files is
> >> probably not a bad thing either.]
> > 
> > Of course, looking at it from a kernel maintainer's perspective, it
> > wouldn't be insane to do this anyway. If we at some point do start to
> > care about cross- process isolation in this way, or if another NT
> > emulator wants to use this interface and does care about cross-process
> > isolation, it'll be necessary. At least it'd make sense to make them
> > separate files even if we don't implement granular permission handling
> > just yet.
> 
> I can think of a few other possible benefits of going with
> per-mutex file descriptors:
> 
> - being able to use poll() for waiting on them individually in
>   combination with other file descriptor based events (socket,
>   signalfd, pidfd, ...)

I can say for sure this isn't going to be useful for Wine, at least not with 
the current design.

It also doesn't really mesh well with the NT design in the first place. 
NTSYNC_IOC_WAIT_ANY differs from poll() in two major ways: it consumes state 
of most object types, and (as coded here) it needs the owner thread ID to be 
specifically passed for mutexes.


Anyway, as Alexandre has informed me I clearly have misunderstood our 
requirements, so I'm going to try to put together something using files 
instead.



  reply	other threads:[~2024-01-25 18:22 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24  0:40 [RFC PATCH 0/9] NT synchronization primitive driver Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device Elizabeth Figura
2024-01-24  7:38   ` Arnd Bergmann
2024-01-24 17:51     ` Elizabeth Figura
2024-01-24 21:26   ` Andy Lutomirski
2024-01-24 22:56     ` Elizabeth Figura
2024-01-25  3:42       ` Elizabeth Figura
2024-01-25 16:47         ` Arnd Bergmann
2024-01-25 18:21           ` Elizabeth Figura [this message]
2024-01-25 18:55         ` Andy Lutomirski
2024-01-25 21:45           ` Elizabeth Figura
2024-01-25  7:41       ` Alexandre Julliard
2024-01-24  0:40 ` [RFC PATCH 2/9] ntsync: Reserve a minor device number and ioctl range Elizabeth Figura
2024-01-24  0:54   ` Greg Kroah-Hartman
2024-01-24  3:43     ` Elizabeth Figura
2024-01-24 12:32       ` Greg Kroah-Hartman
2024-01-24 17:59         ` Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 3/9] ntsync: Introduce NTSYNC_IOC_CREATE_SEM and NTSYNC_IOC_DELETE Elizabeth Figura
2024-01-24  1:14   ` Greg Kroah-Hartman
2024-01-24  3:35     ` Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 4/9] ntsync: Introduce NTSYNC_IOC_PUT_SEM Elizabeth Figura
2024-01-25  8:59   ` Nikolay Borisov
2024-01-24  0:40 ` [RFC PATCH 5/9] ntsync: Introduce NTSYNC_IOC_WAIT_ANY Elizabeth Figura
2024-01-24  7:56   ` Arnd Bergmann
2024-01-24 18:02     ` Elizabeth Figura
2024-01-24 19:52       ` Arnd Bergmann
2024-01-24 22:28         ` Elizabeth Figura
2024-01-25 17:02           ` Arnd Bergmann
2024-01-25 18:30             ` Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 6/9] ntsync: Introduce NTSYNC_IOC_WAIT_ALL Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 7/9] ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 8/9] ntsync: Introduce NTSYNC_IOC_PUT_MUTEX Elizabeth Figura
2024-01-24  7:42   ` Arnd Bergmann
2024-01-24 18:03     ` Elizabeth Figura
2024-01-24 19:53       ` Arnd Bergmann
2024-01-24  0:40 ` [RFC PATCH 9/9] ntsync: Introduce NTSYNC_IOC_KILL_OWNER Elizabeth Figura
2024-01-24  0:59 ` [RFC PATCH 0/9] NT synchronization primitive driver Greg Kroah-Hartman
2024-01-24  1:37   ` Elizabeth Figura
2024-01-24 12:29     ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3785748.kQq0lBPeGt@terabithia \
    --to=zfigura@codeweavers.com \
    --cc=andrealmeid@igalia.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=julliard@winehq.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=wine-devel@winehq.org \
    --cc=wsa@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox