linux-kernel - Re: [PATCH v4 05/28] dax: Document dax dev range tuple

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <67098d5a946b8_9710f29462@iweiny-mobl.notmuch>
Date: Fri, 11 Oct 2024 15:40:58 -0500
From: Ira Weiny <ira.weiny@...el.com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Ira Weiny
	<ira.weiny@...el.com>
CC: Dave Jiang <dave.jiang@...el.com>, Fan Ni <fan.ni@...sung.com>, "Navneet
 Singh" <navneet.singh@...el.com>, Jonathan Corbet <corbet@....net>, "Andrew
 Morton" <akpm@...ux-foundation.org>, Dan Williams <dan.j.williams@...el.com>,
	Davidlohr Bueso <dave@...olabs.net>, Alison Schofield
	<alison.schofield@...el.com>, Vishal Verma <vishal.l.verma@...el.com>,
	<linux-btrfs@...r.kernel.org>, <linux-cxl@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <nvdimm@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 05/28] dax: Document dax dev range tuple

Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:11 -0500
> Ira Weiny <ira.weiny@...el.com> wrote:
> 
> > The device DAX structure is being enhanced to track additional DCD
> > information.
> > 
> > The current range tuple was not fully documented.  Document it prior to
> > adding information for DC.
> > 
> > Suggested-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> > Signed-off-by: Ira Weiny <ira.weiny@...el.com>
> > 
> Isn't this a nested struct?
> https://docs.kernel.org/doc-guide/kernel-doc.html#nested-structs-unions
> 
> I'm not quite sure how we document when it's a nested pointer to a
> a structure.  Is it the same as for a 'normal' nested struct?

In this case I think it best to document the struct and just document the
reference.  See below.

>   
> > ---
> > Changes:
> > [iweiny: move to start of series]
> > ---
> >  drivers/dax/dax-private.h | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/dax/dax-private.h b/drivers/dax/dax-private.h
> > index 446617b73aea..ccde98c3d4e2 100644
> > --- a/drivers/dax/dax-private.h
> > +++ b/drivers/dax/dax-private.h
> > @@ -58,7 +58,10 @@ struct dax_mapping {
> >   * @dev - device core
> >   * @pgmap - pgmap for memmap setup / lifetime (driver owned)
> >   * @nr_range: size of @ranges
> > - * @ranges: resource-span + pgoff tuples for the instance
> > + * @ranges: range tuples of memory used
> > + * @pgoff: page offset
>       @ranges.pgoff?
> etc

Ok yea.

As for the pointer to a structure.  I think the best thing to do is simply
document that structure.

Something like this building on this patch:


diff --git a/drivers/dax/dax-private.h b/drivers/dax/dax-private.h
index ccde98c3d4e2..b9816c933575 100644
--- a/drivers/dax/dax-private.h
+++ b/drivers/dax/dax-private.h
@@ -40,6 +40,12 @@ struct dax_region {
        struct device *youngest;
 };
 
+/**
+ * struct dax_mapping - device to display mapping range attributes
+ * @dev: device representing this range
+ * @range_id: index within dev_dax ranges array
+ * @id: ida of this mapping
+ */
 struct dax_mapping {
        struct device dev;
        int range_id;
@@ -59,9 +65,9 @@ struct dax_mapping {
  * @pgmap - pgmap for memmap setup / lifetime (driver owned)
  * @nr_range: size of @ranges
  * @ranges: range tuples of memory used
- * @pgoff: page offset
- * @range: resource-span
- * @mapping: device to assist in interrogating the range layout
+ * @ranges.pgoff: page offset
+ * @ranges.range: resource-span
+ * @ranges.mapping: reference to the dax_mapping for this range
  */
 struct dev_dax {
        struct dax_region *region;