[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5805970.DvuYhMxLoT@camazotz>
Date: Mon, 12 Aug 2024 12:09:48 -0500
From: Elizabeth Figura <zfigura@...eweavers.com>
To: Peter Zijlstra <peterz@...radead.org>, wine-devel@...ehq.org
Cc: Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
wine-devel@...ehq.org,
André Almeida <andrealmeid@...lia.com>,
Wolfram Sang <wsa@...nel.org>, Andy Lutomirski <luto@...nel.org>,
linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org,
Randy Dunlap <rdunlap@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>,
Boqun Feng <boqun.feng@...il.com>, Elizabeth Figura <zfigura@...eweavers.com>
Subject: Re: [PATCH v5 00/28] NT synchronization primitive driver
On Monday, 10 June 2024 11:58:48 CDT Elizabeth Figura wrote:
> On Sunday, May 19, 2024 3:24:26 PM CDT Elizabeth Figura wrote:
> > This patch series implements a new char misc driver, /dev/ntsync, which is
> > used to implement Windows NT synchronization primitives.
> >
> > NT synchronization primitives are unique in that the wait functions both are
> > vectored, operate on multiple types of object with different behaviour
> > (mutex, semaphore, event), and affect the state of the objects they wait
> > on. This model is not compatible with existing kernel synchronization
> > objects or interfaces, and therefore the ntsync driver implements its own
> > wait queues and locking.
> >
> > This patch series is rebased against the "char-misc-next" branch of
> > gregkh/char-misc.git.
>
> Hi Peter,
>
> Sorry to bother, but now that the Linux merge window is closed could I
> request a review of this revision of the ntsync patch set, please (or a
> review from another locking maintainer)?
>
> I believe I've addressed all of the comments from the last review,
> except those which would have changed the existing userspace API
> (although since the driver isn't really functional yet, maybe this
> would have been fine to do anyway?)
Hi,
Gentle ping on this—this series still needs another review.
If I should go ahead and make "breaking" API changes based on the last
review, please let me know.
Thanks,
Zeb
Powered by blists - more mailing lists