From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 83843E9E2F9 for ; Wed, 11 Feb 2026 12:10:22 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D886510E02E; Wed, 11 Feb 2026 12:10:21 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=collabora.com header.i=@collabora.com header.b="nUtqJfHG"; dkim-atps=neutral Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9840810E02E for ; Wed, 11 Feb 2026 12:10:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770811819; bh=P3p1xktT0pu9lAayEx7pZPThoKCYb789KGT+yGz4pgs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nUtqJfHGW/VdrzUhq/iDU1B2hd6zX59NQ4mJfrsT2c5dw04DR4DnEhGCmF9AokKnF C+CMF5PPdJjMz5SW5qegYgrqo1IodYKgoyvnjoFeW5LGO/e2i0+D5oU07UHpg+1Fbe viwI5ypcndC9O651GCdPHh+jVfwrp9UbrEuj6JyWCH1lniKSuKQuTyhCaJ2thrkl84 7A4Slnfa51Zl4D1RdA1ygpmRwNmhG2lcXY5TVqTt7J6GdC7rzF3YJJHQ2U3L7hbR2b SD+lRbMfgzs9yLUqVNMf3dmLqjvwfWWGdHKC1zZHCmkjiGToIAQTY/52WYOSO44RZF 10+eUMekqxotA== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id B7DB717E1274; Wed, 11 Feb 2026 13:10:18 +0100 (CET) Date: Wed, 11 Feb 2026 13:10:15 +0100 From: Boris Brezillon To: "Danilo Krummrich" Cc: "Philipp Stanner" , , "David Airlie" , "Simona Vetter" , "Alice Ryhl" , "Gary Guo" , "Benno Lossin" , Christian =?UTF-8?B?S8O2bmln?= , "Daniel Almeida" , "Joel Fernandes" , , , Subject: Re: [RFC PATCH 3/4] rust/drm: Add DRM Jobqueue Message-ID: <20260211131015.7bf38cf9@fedora> In-Reply-To: References: <20260203081403.68733-2-phasta@kernel.org> <20260203081403.68733-5-phasta@kernel.org> <20260210155750.5cdbe6cc@fedora> <8ea48ce49f2c7b6fd715dd54c24e755e8ac3262c.camel@mailbox.org> <20260211120742.0e9e7122@fedora> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, 11 Feb 2026 12:19:04 +0100 "Danilo Krummrich" wrote: > On Wed Feb 11, 2026 at 12:07 PM CET, Boris Brezillon wrote: > > I try to avoid using concepts the language I rely on is not friendly > > with. > > It's not really a language limitation. For instance, you can implement lists the > exact same way as they can be implemented in C. It's more that a memory safe > list implementation is quite tricky in general. That's what I mean by trickier to use, they are because of rust safety. And again, that's not a case for saying "nah, rust is not a good fit, it can't do easy-to-use-lists", but rather a good opportunity to think twice about the containers we want to use. > > Lists clearly do have their place. In this specific case, it probably doesn't > matter too much, but in general I'd abstain from not using a list (where it is > the best fit) just because they are tricky in getting them implemented in a > memory safe way. Read my other reply. I'm not saying "don't ever use a list in rust!", I'm saying, "if there are valid alternatives, and they make things slightly simpler, why not use these alternatives". And that's the case here I think, especially since the C side does exactly that (using an xarray over a list). Note how I didn't mention the list under the JobQueue, because for that one, I'm not too sure XArray is a good fit (jobs might be moved around between lists depending on their progress at some point).