rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joel Fernandes <joelagnelf@nvidia.com>
To: Timur Tabi <ttabi@nvidia.com>,
	"gary@garyguo.net" <gary@garyguo.net>,
	John Hubbard <jhubbard@nvidia.com>
Cc: "nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
	Alexandre Courbot <acourbot@nvidia.com>,
	"dakr@kernel.org" <dakr@kernel.org>,
	"lyude@redhat.com" <lyude@redhat.com>,
	"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH 3/7] gpu: nova-core: create debugfs root in PCI init closure
Date: Tue, 16 Dec 2025 18:17:05 -0500	[thread overview]
Message-ID: <b2d3a56b-0bcf-458c-a17b-ac3aa25f2543@nvidia.com> (raw)
In-Reply-To: <1dcf714d18d63e18afc13830e030209214bb2e7c.camel@nvidia.com>

On 12/16/2025 5:29 PM, Timur Tabi wrote:
> On Tue, 2025-12-16 at 17:01 -0500, Joel Fernandes wrote:
>> Could the debugfs Rust abstraction add a directory lookup function
>> `Dir::lookup(name)` method and allow creating sub directories under a known
>> path?
> 
> Actually, that's an excellent idea.

Thanks.
>>  This would let `probe()` find the module-created root directory without
>> needing global state right? Then store references to this on a per-GPU basis
>> that the GSP code can access. 
> 
> Yes, that would work.  I will try to implement this, but I suspect I will need help.

Cool!

>> Alternatively, the first probe can create the root
>> directory, and subsequent probes reuse it without requiring module-level root.
> 
> How would the second probe know that it's not the first, and where would it look up the root Dir?

Since driver_attach() attaches devices to drivers serially AFAIK, simply look up
the debugfs nova root path in probe(), if it does not exist create it. If it
does exist, then you know you're not the first one.

In C, debugfs_lookup() can lookup a name from the root if parent passed is NULL.

Or we can have a Dir::find_or_create() in the debugfs Rust abstraction which
abstracts this which does both.

Alternatively, create nova_core root directory at module init, and then probe()
can assume it exists. That's also robust against any possible concurrent
multiple device probes I think (basically the case where 2 look ups happen
simultaneously and then 2 creates happen simultaneously - one of them error'ing
out and printing a nastygram in dmesg).

thanks,

 - Joel


  reply	other threads:[~2025-12-16 23:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-12 20:49 [PATCH 0/7] gpu: nova-core: expose the logging buffers via debugfs Timur Tabi
2025-12-12 20:49 ` [PATCH 1/7] rust: pci: add PCI device name method Timur Tabi
2025-12-15 11:35   ` Gary Guo
2025-12-15 16:49   ` lyude
2025-12-12 20:49 ` [PATCH 2/7] gpu: nova-core: Replace module_pci_driver! with explicit module init Timur Tabi
2025-12-13 23:46   ` Joel Fernandes
2025-12-15 11:36   ` Gary Guo
2025-12-12 20:49 ` [PATCH 3/7] gpu: nova-core: create debugfs root in PCI init closure Timur Tabi
2025-12-15 11:40   ` Gary Guo
2025-12-15 16:45     ` Timur Tabi
2025-12-16 10:04       ` John Hubbard
2025-12-16 20:28         ` Timur Tabi
2025-12-16 22:01           ` Joel Fernandes
2025-12-16 22:29             ` Timur Tabi
2025-12-16 23:17               ` Joel Fernandes [this message]
2025-12-16 23:29                 ` Timur Tabi
2025-12-12 20:49 ` [PATCH 4/7] gpu: nova-core: implement BinaryWriter for LogBuffer Timur Tabi
2025-12-12 20:49 ` [PATCH 5/7] gpu: nova-core: use pin projection in method boot() Timur Tabi
2025-12-12 20:49 ` [PATCH 6/7] gpu: nova-core: create loginit debugfs entry Timur Tabi
2025-12-15 16:45   ` Timur Tabi
2025-12-12 20:49 ` [PATCH 7/7] gpu: nova-core: create GSP-RM logging buffers debugfs entries Timur Tabi
2025-12-13 23:44   ` Joel Fernandes
2025-12-13 19:19 ` [PATCH 0/7] gpu: nova-core: expose the logging buffers via debugfs Joel Fernandes
2025-12-13 20:47   ` Timur Tabi
2025-12-13 21:49     ` Joel Fernandes

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=b2d3a56b-0bcf-458c-a17b-ac3aa25f2543@nvidia.com \
    --to=joelagnelf@nvidia.com \
    --cc=acourbot@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=ttabi@nvidia.com \
    /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;
as well as URLs for NNTP newsgroup(s).