Lines Matching +full:proc +full:- +full:supply
4 A Maintainer Entry Profile supplements the top-level process
12 --------
14 protocols that enable access to files across a set of network-
20 kernel. An in-kernel NFS server has fast access to files stored
26 ------------
27 The linux-nfs@vger.kernel.org mailing list is a public list. Its
32 The linux-nfs mailing list is archived on `lore.kernel.org <https://lore.kernel.org/linux-nfs/>`_.
37 --------------
38 If you experience an NFSD-related bug on a distribution-built
42 linux-nfs@vger.kernel.org mailing list, where some active triage
48 Please file NFSD-related bugs under the "Filesystems/NFSD"
54 command, is contained in the nfs-utils package. Report problems
55 with those components to linux-nfs@vger.kernel.org. You might be
59 -------------------
64 client. We also test against other popular NFS client implementa-
65 tions regularly at NFS bake-a-thon events (also known as plug-
66 fests). Non-Linux NFS clients are not part of upstream NFSD CI/CD.
69 that interoperates with all standards-compliant NFS client
71 the normative mandates in the IETF's published NFS, RPC, and GSS-API
78 On the rare occasion when a deviation from standard-mandated
80 deficiencies in the standard is a required part of in-code
91 - an NFSD or SUNRPC module parameter
93 - export options in /etc/exports
95 - files under /proc/fs/nfsd/ or /proc/sys/sunrpc/
97 - the NFSD netlink protocol
105 - As with any API, administrative interfaces are difficult to get
108 - Once they are documented and have a legacy of use, administrative
111 - Every new administrative setting multiplies the NFSD test matrix.
113 - The cost of one administrative interface is incremental, but costs
133 - BUG must be avoided if at all possible, as it will frequently
136 - WARN is appropriate only when a full stack trace is useful.
138 - printk can show detailed information. These must not be used
142 - dprintk can show detailed information, but can be enabled only
143 in pre-set groups. The overhead of emitting output makes dprintk
146 - Counters are always on, but provide little information about
149 - static trace points can be enabled individually or in groups
153 - dynamic tracing, such as kprobes or eBPF, are quite flexible but
154 cannot be used in certain environments (eg, full kernel lock-
161 https://github.com/linux-kdevops/kdevops
163 contains several NFS-specific workflows, as well as the community
173 Documentation/process/coding-style.rst
177 - Add new local variables to a function in reverse Christmas tree
180 - Use the kdoc comment style for
181 + non-static functions
185 - All new function names start with ``nfsd_`` for non-NFS-version-
188 - New function names that are specific to NFSv2 or NFSv3, or are
192 - New function names specific to an NFSv4 minor version can be
199 Documentation/process/submitting-patches.rst
212 - A brief problem statement ("what is this patch trying to fix?")
213 with a root-cause analysis.
215 - End-user visible symptoms or items that a support engineer might
218 - A brief explanation of why the patch is the best way to address
221 - Any context that reviewers might need to understand the changes
224 - Any relevant benchmarking results, and/or functional test results.
226 As detailed in Documentation/process/submitting-patches.rst,
231 determined -- that is, no Fixes: tag can be provided. In this case,
244 Patches to NFSD are submitted via the kernel's email-based review
248 nfsd-testing branch at
252 The NFSD subsystem is maintained separately from the Linux in-kernel
268 Cc: linux-nfs@vger.kernel.org and optionally linux-kernel@
276 such as "git send-email" or "stg email format/send", which tend to
284 Please note that, with an e-mail based submission process, series
324 at least two Reviewed-by: notices for patches that are more than
325 simple clean-ups. Reviews are done in public on
326 linux-nfs@vger.kernel.org and are archived on lore.kernel.org.
332 The NFSD maintainers apply patches initially to the nfsd-testing
334 applied while review is ongoing. nfsd-testing is a topic branch,
338 Generally a script-generated "thank you" email will indicate when
339 your patch has been added to the nfsd-testing branch. You can track
340 the progress of your patch using the linux-nfs patchworks instance:
342 https://patchwork.kernel.org/project/linux-nfs/list/
344 While your patch is in nfsd-testing, it is exposed to a variety of
345 test environments, including community zero-day bots, static
349 Each patch that survives in nfsd-testing for the soak period without
350 changes is moved to the nfsd-next branch.
352 The nfsd-next branch is automatically merged into linux-next and
353 fs-next on a nightly basis.
355 Patches that survive in nfsd-next are included in the next NFSD
359 When the upstream merge window closes, the nfsd-next branch is
360 renamed nfsd-fixes, and a new nfsd-next branch is created, based on
361 the upstream -rc1 tag.
363 Fixes that are destined for an upstream -rc release also run the
364 nfsd-testing gauntlet, but are then applied to the nfsd-fixes
371 immediate action (either application to -rc or LTS backport) is
393 which carry a Reported-by: or Fixes: tag are detected as suspicious
394 by security-focused people. We encourage that, after any private
395 review, security-sensitive patches should be posted to linux-nfs@
398 LLM-generated submissions
401 world of LLM-generated code. The NFSD maintainers will entertain
403 LLM-based development tools. Such submissions are held to the
406 - The human contributor identifies themselves via a Signed-off-by:
409 - The human contributor is solely responsible for code provenance
410 and any contamination by inadvertently-included code with a
413 - The human contributor must be able to answer and address review
417 - The contribution is subjected to the same test regimen as all
420 - An indication (via a Generated-by: tag or otherwise) that the
421 contribution is LLM-generated is not required.
430 Clean-up patches
432 The NFSD maintainers discourage patches which perform simple clean-
437 * Addressing long-standing whitespace damage
440 comes at a greater cost than the value of such clean-ups.
445 ----------------------
453 ----------------
456 the linux-nfs@vger.kernel.org mailing list for public review by
486 -----------------------------------
495 - **Contributor** : Anyone who submits a code change, bug fix,
499 - **Outside Contributor** : A contributor who is not a regular actor
504 - **Reviewer** : Someone who is named in the MAINTAINERS file as a
508 - **External Reviewer** : Someone who is not named in the
519 - **Upstream Release Manager** : This role is responsible for
524 - **Bug Triager** : Someone who is a first responder to bug reports
525 submitted to the linux-nfs mailing list or bug trackers, and helps
528 - **Security Lead** : The security lead handles contacts from the
530 with long-term security issues such as supply chain concerns. For
534 - **Testing Lead** : The testing lead builds and runs the test
538 - **LTS Maintainer** : The LTS maintainer is responsible for managing
543 - **Community Manager** : This umpire role can be asked to call balls
546 facilitating discussions on long-term topics such as how to manage