From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: linux-wireless@vger.kernel.org
Cc: Ivo van Doorn <ivdoorn@gmail.com>
Subject: Some questions about missing rfkill details
Date: Sun, 13 Jul 2008 09:22:48 -0300 [thread overview]
Message-ID: <20080713122247.GA6963@khazad-dum.debian.net> (raw)
I was a little burned out from rfkill work, and started looking at a certain
non-mac80211 wireless driver to see how it could be converted to use rfkill
(we already have many examples for mac80211).
The following doubts sprang to mind, I feel the answers to them should be
documented, but I am not sure I have the right answers, so I am asking the
wireless network experts ;-)
1. For wireless network devices, the rfkill class should have as its parent
the main struct net_device for that wireless network device. For
platform device drivers, it should have the platform device as its
parent.
Correct? Incorrect?
2. We will probably benefit long-term from a guideline for naming the rfkill
switches. Currently it is supposed to be a system-wide name, but that's
about all of it.
Thus, what we have may not result on very user-friendly (or useful) names
at all.
It really needs a local part so that drivers that have more than one
rfkill class attached to them (typically, multi-radio devices or platform
devices) can differentiate them. But that means names like "<platform
device name>_bluetooth_sw", "<platform_device_name>_wwan_sw" for platform
drivers, and something else for wireless network devices.
Any ideas of what we should be using, that will actually be useful for
userspace?
Userspace IS supposed to be able to use sysfs to find out what the parent
device is, regardless of the rfkill class name. If it cannot, that
pretty much would make sysfs useless for device configuration through
classes.
If we use the EEPROM MAC, should we document that userspace is to mostly
ignore the name and use the sysfs hierarchy to tie switches to their
parent devices? And MACs can be changed, what should we do, then?
Could we, instead of the MAC, use the main network interface name (and
rename the rfkill class if that name changes? How?), appending to it an
(optional?) small suffix for network devices with more than one
transmitter? What should we use as the suffix?
IMHO, we should also write down if we are to use names like "Mango Bango
Wireless Switch" or "mangobango_sw", etc. I.e. a full naming guideline.
I am not the right person to come up with answers and guidelines for the
above, so I am asking for comments and help.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next reply other threads:[~2008-07-13 12:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-13 12:22 Henrique de Moraes Holschuh [this message]
2008-07-15 17:04 ` Some questions about missing rfkill details Dan Williams
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=20080713122247.GA6963@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=ivdoorn@gmail.com \
--cc=linux-wireless@vger.kernel.org \
/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