STRUCT REGULATORY_REQUEST(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ struct regulatory_request(9) πŸŽ€

okay so this is a page from the Kernel API Manual, and it's about struct regulatory_request β€” literally the little data blob that keeps track of regulatory requests. yes bestie, that kind of regulatory. wireless stuff. country codes. the whole vibe. let's get into it πŸ’…


✨ NAME ✨

struct regulatory_request β€” used to keep track of regulatory requests πŸ¦‹


✨ SYNOPSIS ✨

struct regulatory_request {
    struct rcu_head rcu_head;
    int wiphy_idx;
    enum nl80211_reg_initiator initiator;
    enum nl80211_user_reg_hint_type user_reg_hint_type;
    char alpha2[3];
    enum nl80211_dfs_regions dfs_region;
    bool intersect;
    bool processed;
    enum environment_cap country_ie_env;
    struct list_head list;
 };

🌸 Members 🌸

so every field in this struct is kind of doing its own main character thing, and here's what each one is giving:

  • rcu_head β€” the RCU head struct, used to free the request. it's giving cleanup crew 🧹
  • wiphy_idx β€” this one gets set if this request's initiator is REGDOM_SET_BY_COUNTRY_IE or REGDOM_SET_BY_DRIVER. the wireless core can use it to deal with conflicts and potentially tell users which devices specifically caused those conflicts. so like, receipts. it's holding receipts πŸ”₯
  • initiator β€” tells you who sent this request. could be any of the ones set in nl80211_reg_initiator (NL80211_REGDOM_SET_BY_*). basically the "who started this" field πŸ’€
  • user_reg_hint_type β€” if the initiator was of type NL80211_REGDOM_SET_BY_USER, this classifies what kind of hint got passed along. could be any of the NL80211_USER_REG_HINT_* types. it's the hint's hint, iykyk ✨
  • alpha2 β€” the ISO / IEC 3166 alpha2 country code of the requested regulatory domain. and omg there are a few special codes you need to know:
    • 00 β€” World regulatory domain 🌍
    • 99 β€” built by driver but a specific alpha2 cannot be determined
    • 98 β€” result of an intersection between two regulatory domains 🫢
    • 97 β€” regulatory domain has not yet been configured
  • dfs_region β€” if CRDA responded with a regulatory domain that requires DFS master operation on a known DFS region (NL80211_DFS_*), then dfs_region represents that region. drivers can use this plus the alpha2 to adjust their device's DFS parameters as required. teamwork fr fr 🧚
  • intersect β€” indicates whether the wireless core should intersect the requested regulatory domain with the presently set regulatory domain. like, do these two overlap bestie πŸ€”
  • processed β€” indicates whether or not this request has already been processed. when the last request is processed, it means the currently regulatory domain set on cfg80211 is updated from CRDA and can be used by other regulatory requests. when the last request is not yet processed, we must yield until it is processed before processing any new requests. so yeah β€” no skipping the line πŸ™ˆ
  • country_ie_env β€” lets us know if the AP is telling us we are outdoor, indoor, or if it doesn't matter. the AP is basically doing a vibe check on your location 🌀️
  • list β€” used to insert into the reg_requests_list linked list. the little link in the chain πŸ‘‘

πŸ‘€ SEE ALSO πŸ‘€

  • Kernel file ./include/net/regulatory.h
  • enum environment_cap(9)
  • enum ieee80211_regulatory_flags(9)
  • struct ieee80211_wmm_ac(9)

go read those next, bestie, they're literally iconic πŸ‘‘


okay that's the whole page!! sourced straight from ./include/net, dated October 2026 β€” mwah, sending you off with a kiss and a struct regulatory_request(9) header on top and bottom, periodt πŸ’–πŸŽ€πŸŒ·

πŸ“¦ where this page comes from