linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
	Breno Leitao <leitao@debian.org>
Cc: linux-kernel@vger.kernel.org, john.c.harrison@intel.com
Subject: Re: RFC: configfs attribute description
Date: Wed, 13 Aug 2025 20:06:05 +0200	[thread overview]
Message-ID: <87349vf65u.fsf@t14s.mail-host-address-is-not-set> (raw)
In-Reply-To: <otrtabbmkoutnvku7mmoecw3f7bjqwhxwuxuu4ewhoseixxgpt@fn3dt5tgrnf3>

"Lucas De Marchi" <lucas.demarchi@intel.com> writes:

> Hi,
>
> In the drm/xe drivers we recently started to use configfs for a few
> things that would be added as module parameters in the past. Configfs
> seems a much better fit for us in these cases.
>
> One thing we are missing from module parameters is the description.
> I can point people to https://docs.kernel.org/gpu/xe/xe_configfs.html,
> but having a short description somewhere of each config at runtime would
> be good. I thought of 2 alternatives and would like to know your opinion
> or if there's a different way you envision for this.
>
> 1) Add description to a module info. This would allow to show "all
> configfs attributes this module implements":
>
> configfs.h:
> #define CONFIGFS_ATTR_DESC(_name, _desc) \
> 	MODULE_INFO(configfs_attr_ ## _name, _desc)
>
> xe_configfs.c:
> #define XE_CONFIGFS_ATTR(_name, _desc) \
> 	CONFIGFS_ATTR(, survivability_mode); \
> 	CONFIGFS_ATTR_DESC(survivability_mode, \
> 			   "Bind device in a survivability mode useful to unbrick it")
>
> Or provide a single macro in configfs itself. This would "standardize"
> module info to contain configfs_attr_xxxxx to describe each entry a
> module implements. Main benefit here is that I can take a module and run
>
> 2) Add description in the fs tree itself, similarly to how perf adds a
> .unit: 2 attributes are created, with the second being RO:
>
> ls /sys/kernel/config/xe/0000:03:00.0/
> ...
> survivability_mode
> survivability_mode.description
> ...
>
> This could be done all inside xe itself, but I think it would be better
> if there's a common way across the kernel for that, hence my RFC here.

I'm not against adding this if you want to code it. But is it really
that useful? I always find myself reaching for kernel docs for module
parameters anyway.

I would suggest providing this info in user space tooling (if you use
scripts or a binary to interact with your driver through configfs). Or
you can add the info to the kernel man pages or, as you suggest
yourself, the kernel documentation.

I am curious what others think of this.


Best regards,
Andreas Hindborg



  reply	other threads:[~2025-08-13 18:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <sq3Xfp7-O3mdRYm2TNLAYvv-kw4lb-5S-xl0S9wEcvI72GSytOQIzslrYzZ92KTGLo67af1sraVSpb3sIgMtdQ==@protonmail.internalid>
2025-08-13 15:32 ` RFC: configfs attribute description Lucas De Marchi
2025-08-13 18:06   ` Andreas Hindborg [this message]
2025-08-14  8:55     ` Breno Leitao

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=87349vf65u.fsf@t14s.mail-host-address-is-not-set \
    --to=a.hindborg@kernel.org \
    --cc=john.c.harrison@intel.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.demarchi@intel.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).