Re: [PATCH] MAINTAINERS: Move nvdimm mailing list
Dan Williams writes: > After seeing some users have subscription management trouble, more spam > than other Linux development lists, and considering some of the benefits > of kernel.org hosted lists, nvdimm and persistent memory development is > moving to nvd...@lists.linux.dev. > > The old list will remain up until v5.14-rc1 and shutdown thereafter. > > Cc: Ira Weiny > Cc: Oliver O'Halloran > Cc: Matthew Wilcox > Cc: Jan Kara > Cc: Jonathan Corbet > Cc: Dave Jiang > Cc: Vishal Verma > Signed-off-by: Dan Williams > --- > Documentation/ABI/obsolete/sysfs-class-dax|2 + > Documentation/ABI/removed/sysfs-bus-nfit |2 + > Documentation/ABI/testing/sysfs-bus-nfit | 40 > + > Documentation/ABI/testing/sysfs-bus-papr-pmem |4 +-- > Documentation/driver-api/nvdimm/nvdimm.rst|2 + > MAINTAINERS | 14 - > 6 files changed, 32 insertions(+), 32 deletions(-) Would you like me to take this through docs-next, or did you have another path in mind? Thanks, jon ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH 00/17] Documentation/driver-api: eliminate duplicated words
On Fri, 3 Jul 2020 20:44:45 -0700 Randy Dunlap wrote: > Remove occurrences of duplicated words in Documentation/driver-api/. So most of these, it seems, have been picked up elsewhere. I grabbed #12 and #13; all that's left is the media ones, which I presume Mauro will take. Thanks, jon ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH] Documentation: fixes to the maintainer-entry-profile template
On Tue, 26 May 2020 18:17:13 -0700 Randy Dunlap wrote: > From: Randy Dunlap > > Do some wordsmithing and copy editing on the maintainer-entry-profile > profile (template, guide): > - fix punctuation > - fix some wording > - use "-rc" consistently > > Signed-off-by: Randy Dunlap > Cc: Dan Williams > Cc: linux-nvdimm@lists.01.org > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > --- > Documentation/maintainer/maintainer-entry-profile.rst | 12 +- > 1 file changed, 6 insertions(+), 6 deletions(-) Applied, thanks. jon ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH] nvdimm: fixes to maintainter-entry-profile
On Thu, 21 May 2020 09:51:37 -0700 Randy Dunlap wrote: > From: Randy Dunlap > > Fix punctuation and wording in a few places. > > Signed-off-by: Randy Dunlap > Cc: Dan Williams > Cc: Vishal Verma > Cc: Dave Jiang > Cc: Ira Weiny > Cc: linux-nvdimm@lists.01.org > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > --- > Documentation/nvdimm/maintainer-entry-profile.rst | 14 ++-- > 1 file changed, 7 insertions(+), 7 deletions(-) Applied, thanks. jon ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH] doc: nvdimm: remove reference to non-existent CONFIG_NFIT_TEST
On Wed, 15 Apr 2020 23:16:50 +0200 Michal Suchanek wrote: > The test driver is in tools/testing/nvdimm and cannot be selected by a > config option. > > Signed-off-by: Michal Suchanek > --- > Documentation/driver-api/nvdimm/nvdimm.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst > b/Documentation/driver-api/nvdimm/nvdimm.rst > index 08f855cbb4e6..79c0fd39f2af 100644 > --- a/Documentation/driver-api/nvdimm/nvdimm.rst > +++ b/Documentation/driver-api/nvdimm/nvdimm.rst > @@ -278,8 +278,8 @@ by a region device with a dynamically assigned id > (REGION0 - REGION5). > be contiguous in DPA-space. > > This bus is provided by the kernel under the device > -/sys/devices/platform/nfit_test.0 when CONFIG_NFIT_TEST is enabled and > -the nfit_test.ko module is loaded. This not only test LIBNVDIMM but the > +/sys/devices/platform/nfit_test.0 when the nfit_test.ko module from > +tools/testing/nvdimm is loaded. This not only test LIBNVDIMM but the > acpi_nfit.ko driver as well. Applied, thanks. jon ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v3 0/3] Maintainer Entry Profiles
On Mon, 25 Nov 2019 08:41:16 -0800 Dan Williams wrote: > Apologies for all of the above. I rushed it without considering the > docs submission basics. Thanks for moving this forward. That's OK, I don't have a maintainer profile for you to refer to yet :) Thanks, jon ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v3 0/3] Maintainer Entry Profiles
On Sun, 24 Nov 2019 12:59:42 -0800 Dan Williams wrote: > Changes since v2 [1]: > - Drop any consideration for coding style concerns in the profile. It > was a minor aspect of the proposal that generated the bulk of the > feedback on v2. Lets make progress on the rest. > > - Clarify that the "Submit Checklist Addendum" can also include details > that submitters need to take into account before even beginning to > craft a patch. This is in response to the RISC-V use case of > declaring specification readiness as a patch gate, and is now also used > by the libnvdimm subsystem to clarify details about ACPI NVDIMM Device > Specific Method specifications. (Paul) > > - Non-change from v2: Kees had asked for a common directory for all > profiles to live, but Mauro noted that this could be handled later > with some scripting to post-process the MAINTAINERS file, or otherwise > converting MAINTAINERS to ReST. > > - Clarify the cover letter to focus on the contributor focused > Maintainer Entry Profiles, and defer discussion of a maintainer > focused Handbook. OK, some notes... I wish you'd done this against docs-next, that would have saved me resolving a few conflicts on the MAINTAINERS file. I thought we'd agreed to move this to the process book? That said, I now wonder about that...today I read the document as information for maintainers on how to create their profile, so its location in the maintainers manual is appropriate. There were a number RST issues and warnings that I fixed up with the following add-on patch; it was mostly a matter of adding blank lines where needed. One other warning resulted from the nvdimm profile document not being linked into the TOC tree. I've added a TOC section to the new document to bring these things together for now. This is almost certainly not what we want in the longer term. It was tempting to ask for this stuff to be fixed up, but I didn't want to delay this work any longer. So it's applied to docs-next; unless something explodes in the very near future, I intend to push this for 5.5. Thanks, jon >From 0bfa52a43ec085c2f5eb2c35fcc6cf73bb802eae Mon Sep 17 00:00:00 2001 From: Jonathan Corbet Date: Mon, 25 Nov 2019 08:42:12 -0700 Subject: [PATCH 2/2] docs: fix up the maintainer profile document Add blank lines where needed to get the document to render properly. Also add a TOC of existing profiles just so that the nvdimm profile is linked into the toctree, is discoverable, and doesn't generate a warning. Signed-off-by: Jonathan Corbet --- .../maintainer/maintainer-entry-profile.rst | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst index 51de3b9e606d..3eaddc8ac56d 100644 --- a/Documentation/maintainer/maintainer-entry-profile.rst +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -18,7 +18,9 @@ Provide an introduction to how the subsystem operates. While MAINTAINERS tells the contributor where to send patches for which files, it does not convey other subsystem-local infrastructure and mechanisms that aid development. + Example questions to consider: + - Are there notifications when patches are applied to the local tree, or merged upstream? - Does the subsystem have a patchwork instance? Are patchwork state @@ -55,6 +57,7 @@ be settled in soaking in linux-next in advance of the merge window opening. Clarify for the submitter the key dates (in terms rc release week) that patches might considered for merging and when patches need to wait for the next -rc. At a minimum: + - Last -rc for new feature submissions: New feature submissions targeting the next merge window should have their first posting for consideration before this point. Patches that @@ -72,6 +75,7 @@ wait for the next -rc. At a minimum: resubmit for the following merge window. Optional: + - First -rc at which the development baseline branch, listed in the overview section, should be considered ready for new submissions. @@ -85,3 +89,14 @@ section can also indicate a preferred style of update like, resend the full series, or privately send a reminder email. This section might also list how review works for this code area and methods to get feedback that are not directly from the maintainer. + +Existing profiles +- + +For now, existing maintainer profiles are listed here; we will likely want +to do something different in the near future. + +.. toctree:: + :maxdepth: 1 + + ../nvdimm/maintainer-entry-profile -- 2.21.0 ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
Hi, Dan, A month or so ago I wrote... > > See Documentation/maintainer/maintainer-entry-profile.rst for more details, > > and a follow-on example profile for the libnvdimm subsystem. > > Thus far, the maintainer guide is focused on how to *be* a maintainer. > This document, instead, is more about how to deal with specific > maintainers. So I suspect that Documentation/maintainer might be the > wrong place for it. > > Should we maybe place it instead under Documentation/process, or even > create a new top-level "book" for this information? Unless I missed it, I've not heard back from you on this. I'd like to get this stuff pulled in for 5.5 if possible... would you object if I were to apply your patches, then tack on a move over to the process guide? Thanks, jon ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile
On Wed, 11 Sep 2019 08:48:54 -0700 Dan Williams wrote: > As presented at the 2018 Linux Plumbers conference [1], the Maintainer > Entry Profile (formerly Subsystem Profile) is proposed as a way to reduce > friction between committers and maintainers and encourage conversations > amongst maintainers about common best practices. While coding-style, > submit-checklist, and submitting-drivers lay out some common expectations > there remain local customs and maintainer preferences that vary by > subsystem. > > The profile contains short answers to some of the common policy questions a > contributor might have that are local to the subsystem / device-driver, or > otherwise not covered by the top-level process documents. > > Overview: General introduction to how the subsystem operates > Submit Checklist Addendum: Mechanical items that gate submission staging > Key Cycle Dates: > - Last -rc for new feature submissions: Expected lead time for submissions > - Last -rc to merge features: Deadline for merge decisions > Coding Style Addendum: Clarifications of local style preferences > Resubmit Cadence: When to ping the maintainer > Checkpatch / Style Cleanups: Policy on pure cleanup patches So I'm finally back home after my European tour, and I have it on good authority that my bag might even get here eventually too. That means I'm digging through a pile of docs stuff I've been neglecting badly... My intention is to apply these patches. But as I was reading through them, one little nagging thing came to mind... > See Documentation/maintainer/maintainer-entry-profile.rst for more details, > and a follow-on example profile for the libnvdimm subsystem. Thus far, the maintainer guide is focused on how to *be* a maintainer. This document, instead, is more about how to deal with specific maintainers. So I suspect that Documentation/maintainer might be the wrong place for it. Should we maybe place it instead under Documentation/process, or even create a new top-level "book" for this information? Thanks, jon ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
On Wed, 11 Sep 2019 16:11:29 -0600 Jens Axboe wrote: > On 9/11/19 12:43 PM, Dan Carpenter wrote: > > > > I kind of hate all this extra documentation because now everyone thinks > > they can invent new hoops to jump through. > > FWIW, I completely agree with Dan (Carpenter) here. I absolutely > dislike having these kinds of files, and with subsystems imposing weird > restrictions on style (like the quoted example, yuck). > > Additionally, it would seem saner to standardize rules around when > code is expected to hit the maintainers hands for kernel releases. Both > yours and Martins deals with that, there really shouldn't be the need > to have this specified in detail per sub-system. This sort of objection came up at the maintainers summit yesterday; the consensus was that, while we might not like subsystem-specific rules, they do currently exist and we're just documenting reality. To paraphrase Phillip K. Dick, reality is that which, when you refuse to document it, doesn't go away. So I'm expecting to take this kind of stuff into Documentation/. My own personal hope is that it can maybe serve to shame some of these "local quirks" out of existence. The evidence from this brief discussion suggests that this might indeed happen. Thanks, jon ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v2] Documentation: nvdimm: Fix typo
On Thu, 9 May 2019 15:40:49 +0800 Shiyang Ruan wrote: > Remove the extra 'we '. > > Signed-off-by: Shiyang Ruan > --- > Documentation/nvdimm/nvdimm.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/nvdimm/nvdimm.txt b/Documentation/nvdimm/nvdimm.txt > index e894de69915a..1669f626b037 100644 > --- a/Documentation/nvdimm/nvdimm.txt > +++ b/Documentation/nvdimm/nvdimm.txt > @@ -284,8 +284,8 @@ A bus has a 1:1 relationship with an NFIT. The current > expectation for > ACPI based systems is that there is only ever one platform-global NFIT. > That said, it is trivial to register multiple NFITs, the specification > does not preclude it. The infrastructure supports multiple busses and > -we we use this capability to test multiple NFIT configurations in the > -unit test. > +we use this capability to test multiple NFIT configurations in the unit > +test. Applied, thanks. I note this has languished for a bit; please don't hesitate to ping after a week or so if you don't get a response on a patch posting. jon ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v3 15/18] Documentation: kunit: add documentation for KUnit
On Tue, 14 May 2019 16:19:02 -0700 Brendan Higgins wrote: > Hmmm...probably premature to bring this up, but Documentation/dev-tools/ > is kind of thrown together. Wait a minute, man... *I* created that directory, are you impugning my work? :) But yes, "kind of thrown together" is a good description of much of Documentation/. A number of people have been working for years to make that better, with some success, but there is a long way to go yet. The dev-tools directory is an improvement over having that stuff scattered all over the place — at least it's actually thrown together — but it's not the end point. > It would be nice to provide a coherent overview, maybe provide some > basic grouping as well. > > It would be nice if there was kind of a gentle introduction to the > tools, which ones you should be looking at, when, why, etc. Total agreement. All we need is somebody to write it! :) Thanks, jon ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v3 15/18] Documentation: kunit: add documentation for KUnit
On Tue, 14 May 2019 11:08:10 -0700 Brendan Higgins wrote: > > Naturally, though, I have one request: I'd rather not see this at the top > > level, which is more than crowded enough as it is. Can this material > > please go into the development tools book, alongside the kselftest > > documentation? > > Oh yeah, that seems like the obvious home for this in hindsight. Sorry > about that. Will fix in next revision! No need to apologize - I have to say the same thing to everybody :) Thanks, jon ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v3 15/18] Documentation: kunit: add documentation for KUnit
On Mon, 13 May 2019 22:42:49 -0700 Brendan Higgins wrote: > Add documentation for KUnit, the Linux kernel unit testing framework. > - Add intro and usage guide for KUnit > - Add API reference > > Signed-off-by: Felix Guo > Signed-off-by: Brendan Higgins > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Logan Gunthorpe > --- > Changes Since Last Revision: > - Addressed reference to incorrect number of sections, as per Randy's >comment. > - Make section underlines same length as the section title, as per >Randy's comments. > --- > Documentation/index.rst | 1 + > Documentation/kunit/api/index.rst | 16 + > Documentation/kunit/api/test.rst | 14 + > Documentation/kunit/faq.rst | 62 > Documentation/kunit/index.rst | 79 > Documentation/kunit/start.rst | 180 ++ > Documentation/kunit/usage.rst | 575 ++ Certainly it's great to see all this documentation coming with this feature! Naturally, though, I have one request: I'd rather not see this at the top level, which is more than crowded enough as it is. Can this material please go into the development tools book, alongside the kselftest documentation? Thanks, jon ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v2] acpi: nfit: document sysfs interface
On Fri, 23 Feb 2018 18:24:48 +0530 Aishwarya Pant wrote: > This is an attempt to document the nfit sysfs interface. The > descriptions have been collected from git commit logs and the ACPI > specification 6.2. Applied to the docs tree, thanks. jon ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v3 05/11] PCI/P2PDMA: Add P2P DMA driver writer's documentation
On Mon, 12 Mar 2018 13:35:19 -0600 Logan Gunthorpe wrote: > Add a restructured text file describing how to write drivers > with support for P2P DMA transactions. The document describes > how to use the APIs that were added in the previous few > commits. > > Also adds an index for the PCI documentation tree even though this > is the only PCI document that has ben converted to restructured text > at this time. This all seems good, but...could we consider moving this documentation to driver-api/PCI as it's converted to RST? That would keep it together with similar materials and bring a bit more coherence to Documentation/ as a whole. Thanks, jon ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 1/2] dax: some small updates to dax.txt documentation
On Wed, 20 Jul 2016 16:18:57 -0700 Andrew Morton wrote: > > So how were you thinking of routing these? I can take the docs fix, of > > course, but part 2 is a bit out of my turf. If you want to route them > > together via another tree that's fine, just let me know. > > I have them queued. You were cc'ed on the commit! Interesting, I can't find that cc in my archive anywhere. It seems it went astray somewhere? Thanks, jon ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 1/2] dax: some small updates to dax.txt documentation
On Thu, 14 Jul 2016 15:40:48 -0600 Ross Zwisler wrote: > These are originally from Matthew Wilcox and were part of his huge > "mm,fs,dax: Change ->pmd_fault to ->huge_fault" patch that was part of PUD > support. > > I'm breaking these small changes out as they stand on their own and add > useful information to Documentation/filesystems/dax.txt. So how were you thinking of routing these? I can take the docs fix, of course, but part 2 is a bit out of my turf. If you want to route them together via another tree that's fine, just let me know. Thanks, jon ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
