dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joelagnelf@nvidia.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
	dri-devel@lists.freedesktop.org, dakr@kernel.org,
	acourbot@nvidia.com, Alistair Popple <apopple@nvidia.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alex Gaynor <alex.gaynor@gmail.com>,
	Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
	bjorn3_gh@protonmail.com, Benno Lossin <lossin@kernel.org>,
	Andreas Hindborg <a.hindborg@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	Trevor Gross <tmgross@umich.edu>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	John Hubbard <jhubbard@nvidia.com>, Timur Tabi <ttabi@nvidia.com>,
	joel@joelfernandes.org, Elle Rhumsaa <elle@weathered-steel.dev>,
	Daniel Almeida <daniel.almeida@collabora.com>,
	nouveau@lists.freedesktop.org
Subject: Re: [PATCH 7/7] nova-core: mm: Add data structures for page table management
Date: Mon, 3 Nov 2025 14:21:26 -0500	[thread overview]
Message-ID: <226d7dcb-26c3-4477-b1e9-2b837dc17cd1@nvidia.com> (raw)
In-Reply-To: <CANiq72=SSQ5nSjt9yzX_A3Tgo2ByGM5CV0VqFnF1cTOzrZ-pbg@mail.gmail.com>

Hi Miguel,

On 10/20/2025 5:30 PM, Miguel Ojeda wrote:
> Hi Joel,
> 
> A few nits below (I do sometimes this kind of docs review to try to
> keep a consistent style across all Rust code).

Thanks a lot for these, I studied all of the suggestions and agree with them.
May I also suggest to add some of these suggestions to the kernel rust coding
guidelines document, that way others new to sending rust kernel patches don't
miss it (example not adding a period at the end of a markdown doc header.). But
I will make it a point to check all my patches to make sure it confirms to the
suggestions.

Also a lot of your suggestions are related to how it looks it rustdoc, so I will
try to build rustdoc and see what it looks like as well, to get an idea of when
things in my patches could be improved.

thanks,

 - Joel


> 
> On Mon, Oct 20, 2025 at 8:56 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>>
>> +//!     .set_table_frame_number(new_table.frame_number());
>> +//! // Call a function to write PDE to VRAM address
> 
> Newline between these. Period ad the end.
> 
>> +//! ## Given a PTE, Get or allocate a PFN (page frame number).
> 
> In headers, no period at the end. Also, is "Get" intended to be capitalized?
> 
>> +//!     // Call a function to read 64-bit PTE value from VRAM address
> 
> Period at the end too (more of these elsewhere).
> 
>> +//!     if pte.valid() {
>> +//!         // Return physical frame number from existing mapping
>> +//!         Ok(Pfn::new(pte.frame_number()))
> 
> Early returns where possible, like in C, i.e. to avoid indentation on
> big `else` branches.
> 
>> +/// Memory size constants
>> +pub(crate) const KB: usize = 1024;
>> +pub(crate) const MB: usize = KB * 1024;
> 
> The docs will only apply to the first item, so this probably was meant
> to be a `//` instead of a `///`.
> 
> Or you could use a module to contain these (and then possibly `use`
> them outside), and then you can have docs in the module itself, but
> that is heavier.
> 
>> +/// Page size: 4 KiB
>> +pub(crate) const PAGE_SIZE: usize = 4 * KB;
> 
> `rustdoc` would eventually render the value and the non-evaluated
> expression, and in the source code it already says `4 * KB`, so I
> think repeating the value isn't needed, unless you mean to show it is
> really a multiple of 2.
> 
>> +pub(crate) enum PageTableLevel {
>> +    Pdb, // Level 0 - Page Directory Base
>> +    L1,  // Level 1
>> +    L2,  // Level 2
>> +    L3,  // Level 3 - Dual PDE (128-bit entries)
>> +    L4,  // Level 4 - PTEs
> 
> In this case, I think you meant the other way around, i.e. actual
> docs: `///` instead of `//`.
> 
> (Also, unless there is a particular reason (e.g. it is a big table),
> please generally put comments on top of things, not at the side, which
> matches closer to what is needed for docs.)
> 
>> +    /// Convert an Address to a frame number.
> 
> These should eventually be intra-doc links, but at least please use
> for the moment backticks when referring to Rust items like types etc.
> 
>> +    /// # Example
> 
> We always use the plural for these section headers, even if there is a
> single item (e.g. single example).
> 
>> +    /// ```no_run
>> +    /// let va = VirtualAddress::default();
>> +    /// let pte_idx = va.level_index(PageTableLevel::L4);
>> +    /// ```
> 
> This will need some `use` lines -- not needed now, but just as a
> reminder that these will get actually built eventually.
> 
>> +    /// Get raw u64 value.
> 
> Intra-doc link or at least backticks.
> 
>> +    /// The valid bit is inverted so add an accessor to flip it.
>> +    pub(crate) fn set_valid(&self, value: bool) -> Pde {
> 
> This docs string sounds like a commit message.
> 
>> +/// Dual PDE at Level 3 - 128-bit entry containing both LPT and SPT pointers.
>> +/// Lower 64 bits = big/large page, upper 64 bits = small page.
> 
> It sounds like a few of these details should be on its own paragraph
> to avoid having them in the short description (title).
> 
>> +/// // Call a function to read dual PDE from VRAM address
>> +/// let mut dual_pde: DualPde = read_dual_pde(dpde_addr)?;
>> +/// // Call a function to allocate a page table and return its VRAM address
>> +/// let spt_addr = allocate_page_table()?;
>> +/// dual_pde.set_spt(Pfn::from(spt_addr), AperturePde::VideoMemory);
>> +/// // Call a function to write dual PDE to VRAM address
>> +/// write_dual_pde(dpde_addr, dual_pde)?;
> 
> Newlines before the comments, i.e. between "conceptual blocks".
> 
>> +    pub lpt: Pde, // Large/Big Page Table pointer (2MB pages) - bits 63:0 (lower)
>> +    pub spt: Pde, // Small Page Table pointer (4KB pages) - bits 127:64 (upper)
> 
> Docs instead of comments.
> 
>> +    /// Check if has valid Small Page Table.
> 
> Missing word?
> 
> Thanks!
> 
> Cheers,
> Miguel


  reply	other threads:[~2025-11-03 19:21 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20 18:55 [PATCH 0/7] Pre-requisite patches for mm and irq in nova-core Joel Fernandes
2025-10-20 18:55 ` [PATCH 1/7] docs: rust: Fix a few grammatical errors Joel Fernandes
2025-10-20 21:21   ` John Hubbard
2025-10-20 21:33   ` Miguel Ojeda
2025-10-20 23:23     ` Joel Fernandes
2025-10-20 18:55 ` [PATCH 2/7] gpu: nova-core: Add support to convert bitfield to underlying type Joel Fernandes
2025-10-20 21:25   ` John Hubbard
2025-10-22  6:25   ` Alexandre Courbot
2025-10-22 17:51     ` Joel Fernandes
2025-10-20 18:55 ` [PATCH 3/7] docs: gpu: nova-core: Document GSP RPC message queue architecture Joel Fernandes
2025-10-20 21:49   ` John Hubbard
2025-10-22  1:43   ` Bagas Sanjaya
2025-10-22 11:16   ` Alexandre Courbot
2025-10-20 18:55 ` [PATCH 4/7] docs: gpu: nova-core: Document the PRAMIN aperture mechanism Joel Fernandes
2025-10-20 19:36   ` John Hubbard
2025-10-20 19:48     ` Joel Fernandes
2025-10-20 20:42       ` John Hubbard
2025-10-20 20:45         ` Joel Fernandes
2025-10-20 22:08   ` John Hubbard
2025-10-22  2:09   ` Bagas Sanjaya
2025-10-20 18:55 ` [PATCH 5/7] gpu: nova-core: Add support for managing GSP falcon interrupts Joel Fernandes
2025-10-20 22:35   ` John Hubbard
2025-10-21 18:42     ` Joel Fernandes
2025-10-22  6:48     ` Alexandre Courbot
2025-10-22 21:09       ` Joel Fernandes
2025-10-22 23:16         ` John Hubbard
2025-10-22  6:47   ` Alexandre Courbot
2025-10-22 21:05     ` Joel Fernandes
2025-10-20 18:55 ` [PATCH 6/7] nova-core: mm: Add support to use PRAMIN windows to write to VRAM Joel Fernandes
2025-10-22  2:18   ` John Hubbard
2025-10-22 17:48     ` Joel Fernandes
2025-10-22 20:43       ` Joel Fernandes
2025-10-24 11:31       ` Alexandre Courbot
2025-10-22 10:41   ` Alexandre Courbot
2025-10-22 22:04     ` Joel Fernandes
2025-10-24 11:39       ` Alexandre Courbot
2025-10-20 18:55 ` [PATCH 7/7] nova-core: mm: Add data structures for page table management Joel Fernandes
2025-10-20 20:59   ` John Hubbard
2025-10-21 18:26     ` Joel Fernandes
2025-10-21 20:30       ` John Hubbard
2025-10-21 21:58         ` Joel Fernandes
2025-10-20 21:30   ` Miguel Ojeda
2025-11-03 19:21     ` Joel Fernandes [this message]
2025-11-04 17:54       ` Miguel Ojeda
2025-11-04 18:18         ` Danilo Krummrich
2025-11-03 19:29     ` John Hubbard
2025-11-04 17:56       ` Miguel Ojeda
2025-11-05  2:25         ` John Hubbard
2025-10-22 11:21   ` Alexandre Courbot
2025-10-22 19:13     ` Joel Fernandes
2025-10-20 21:20 ` [PATCH 0/7] Pre-requisite patches for mm and irq in nova-core John Hubbard
2025-10-21 18:29   ` Joel Fernandes
2025-10-22  6:57 ` Alexandre Courbot
2025-10-22 21:30   ` Joel Fernandes
2025-10-24 11:51     ` Alexandre Courbot

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=226d7dcb-26c3-4477-b1e9-2b837dc17cd1@nvidia.com \
    --to=joelagnelf@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=elle@weathered-steel.dev \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=tzimmermann@suse.de \
    /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