From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH 0/2] eventfd: simplify signal helpers Date: Tue, 18 Jul 2023 12:56:38 -0300 Message-ID: References: <20230630155936.3015595-1-jaz@semihalf.com> <20230714-gauner-unsolidarisch-fc51f96c61e8@brauner> <20230717130831.0f18381a.alex.williamson@redhat.com> <20230717165203.4ee6b1e6.alex.williamson@redhat.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1689695800; x=1692287800; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Tjh+qVHNBsaCt+fpZytXbv4JtN2Kf+QfiKBiC+OQp3c=; b=bYsTsBY1ioUL9k8drjTPCTw/fEJ0EAlGX5g4owJLPMPxN2CHLKUwbHRdsGU8yNpkgq tSJhCUQojCe7iZMsDT/aY34J1oz2QHRzCjLM+KqEBEo9M8BD2KOp45IRPvgTMkckJ6dq H9fFQEgiHBZaevHiGZSqEfXqcoEtLjezHUCteBqtpUndGthYRfcrzEkhL4CGHaIFAcmx 6wdKboUdDaPeOVdQT0aOEr8C1+gySsRWrc1UqrjcLLXuhZDet2FHUgbuPzKGfDMScL/V K78x7SFpD7MaWzPqAIp0HWYQyARw7uG7tneLlNjtBlR/Fv5UIeG6Vm/K9G6rR6HJEl7q 8oNQ== Content-Disposition: inline In-Reply-To: <20230717165203.4ee6b1e6.alex.williamson@redhat.com> Sender: owner-linux-aio@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alex Williamson Cc: Grzegorz Jaszczyk , Christian Brauner , linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-usb@vger.kernel.org, Matthew Rosato , Paul Durrant , Tom Rix , Jason Wang , dri-devel@lists.freedesktop.org, Michal Hocko , linux-mm@kvack.org, Kirti Wankhede , Paolo Bonzini , Jens Axboe , Vineeth Vijayan , Diana Craciun , Alexander Gordeev , Xuan Zhuo , Shakeel Butt , Vasily Gorbik , Leon Romanovsky , Harald Freudenberger , Fei Li , x86@kernel.org, Roman Gushchin On Mon, Jul 17, 2023 at 04:52:03PM -0600, Alex Williamson wrote: > On Mon, 17 Jul 2023 19:12:16 -0300 > Jason Gunthorpe wrote: > > > On Mon, Jul 17, 2023 at 01:08:31PM -0600, Alex Williamson wrote: > > > > > What would that mechanism be? We've been iterating on getting the > > > serialization and buffering correct, but I don't know of another means > > > that combines the notification with a value, so we'd likely end up with > > > an eventfd only for notification and a separate ring buffer for > > > notification values. > > > > All FDs do this. You just have to make a FD with custom > > file_operations that does what this wants. The uAPI shouldn't be able > > to tell if the FD is backing it with an eventfd or otherwise. Have the > > kernel return the FD instead of accepting it. Follow the basic design > > of eg mlx5vf_save_fops > > Sure, userspace could poll on any fd and read a value from it, but at > that point we're essentially duplicating a lot of what eventfd provides > for a minor(?) semantic difference over how the counter value is > interpreted. Using an actual eventfd allows the ACPI notification to > work as just another interrupt index within the existing vfio IRQ > uAPI. Yes, duplicated, sort of, whatever the "ack" is to allow pushing a new value can be revised to run as part of the read. But I don't really view it as a minor difference. eventfd is a counter. It should not be abused otherwise, even if it can be made to work. It really isn't an IRQ if it is pushing an async message w/data. Jason -- To unsubscribe, send a message with 'unsubscribe linux-aio' in the body to majordomo@kvack.org. For more info on Linux AIO, see: http://www.kvack.org/aio/ Don't email: aart@kvack.org