linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Ping-Ke Shih <pkshih@realtek.com>,
	tony0620emma@gmail.com, linux-wireless@vger.kernel.org,
	steventing@realtek.com, David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Subject: wireless: guidelines for user space interfaces
Date: Mon, 11 Oct 2021 12:23:54 +0300	[thread overview]
Message-ID: <87mtnf52z9.fsf_-_@codeaurora.org> (raw)
In-Reply-To: <YMPqT8VH5alHQXXA@google.com> (Brian Norris's message of "Fri, 11 Jun 2021 15:57:19 -0700")

(changing subject, was "Re: [PATCH v2 2/2] rtw88: add debugfs to force lowest basic rate")

Brian Norris <briannorris@chromium.org> writes:

> BTW, if we have clear guidelines on debugfs, module parameters, etc.,
> maybe those should be going on the wiki? I know this came up before:
>
> https://lore.kernel.org/linux-wireless/87d09u7tyr.fsf@codeaurora.org/
>
> At this point, I'm willing to write such guidelines, if I get an ack
> from the relevant folks (I guess that's just Kalle?). It probably
> belongs somewhere in this tree:
>
> https://wireless.wiki.kernel.org/en/developers/documentation
>
> similar to this:
> https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api
> except it's not really an nl80211 thing. Suggestions welcome.

I think this is a very good idea. Having general guidelines for wireless
drivers using user space interfaces would help both people submitting
patches and also people like me reviewing the patches.

We should try to get an ack for the guidelines at least from Johannes,
but I would prefer also involve Jakub and Dave (CCed) as they might have
some input from the network subsystem point of view.

Just to get this started, here's a draft list I came up of different
user space interfaces upstream wireless drivers are using:

* generic nl80211 (excluding testmode and vendor commands)

* nl80211 testmode commands

* nl80211 vendor commands

* sysfs[1]

* debugfs

* relayfs

* configfs[1]

* module parameters

* thermal subsystem

* firmware_request()

I'm not saying that we need to document all these in the first version,
I'm just trying to come up a comprehensive overview how wireless drivers
interact with the user space. And I'm sure I missed something. so please
do fill in.

> Side note: it could really use some cleanup -- like this page:
> https://wireless.wiki.kernel.org/en/developers/process

Heh, that is old information. TBH in practise I maintain only the
submittingpatches page (link in the signature), other pages I rarely
touch. And naturally I also look after ath10k and ath11k pages.

Any volunteers to clean that up?

[1] Actually I don't know if there are any valid use cases for sysfs and
    configfs at the moment, but I'll include them in the list for
    completeness.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2021-10-11  9:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-22  3:04 [PATCH v2 1/2] rtw88: follow the AP basic rates for tx mgmt frame Ping-Ke Shih
2021-04-22  3:04 ` [PATCH v2 2/2] rtw88: add debugfs to force lowest basic rate Ping-Ke Shih
2021-06-11 22:57   ` Brian Norris
2021-10-11  9:23     ` Kalle Valo [this message]
2021-10-11  9:40       ` wireless: guidelines for user space interfaces Arend van Spriel
2021-10-11 10:47         ` Kalle Valo
2021-11-01 11:00     ` [PATCH v2 2/2] rtw88: add debugfs to force lowest basic rate Kalle Valo
2021-11-02  2:29       ` Pkshih
2021-06-10  3:03 ` [PATCH v2 1/2] rtw88: follow the AP basic rates for tx mgmt frame Pkshih
2021-06-11 22:44 ` Brian Norris

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=87mtnf52z9.fsf_-_@codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=briannorris@chromium.org \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pkshih@realtek.com \
    --cc=steventing@realtek.com \
    --cc=tony0620emma@gmail.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).