Hello linux-wireless,
I'm a developer of libdrc, a project that allows Linux computers to
control a Wii U GamePad. Because of how the device operates, our
library needs to be able to read the TSF value of the access point
device from userland.
We currently have a hacky patch that works for our use cases, but it
would be a lot more convenient if that feature could be upstreamed.
What would be the best way to proceed?
Our current patch:
https://bitbucket.org/memahaxx/drc-mac80211/commits/4a9823cf2a6733bc15a05cffaebd8850d07451a7
Thanks,
--
Pierre "delroth" Bourdon <[email protected]>
Software Engineer @ Z?rich, Switzerland
http://code.delroth.net/
Pierre Bourdon <[email protected]> writes:
> I'm a developer of libdrc, a project that allows Linux computers to
> control a Wii U GamePad. Because of how the device operates, our
> library needs to be able to read the TSF value of the access point
> device from userland.
Just out of curiosity, how do you use TSF exactly?
--
Kalle Valo
On Tue, Dec 31, 2013 at 9:23 AM, Kalle Valo <[email protected]> wrote:
> Pierre Bourdon <[email protected]> writes:
>
>> I'm a developer of libdrc, a project that allows Linux computers to
>> control a Wii U GamePad. Because of how the device operates, our
>> library needs to be able to read the TSF value of the access point
>> device from userland.
>
> Just out of curiosity, how do you use TSF exactly?
The Wii U GamePad reads the TSF and uses that to configure its
internal clock. All video and audio packets sent to the device have to
contain a timestamp that roughly matches (1000us window) this internal
clock. This means our library has to be able to read the TSF from the
AP NIC to generate these timestamps.
--
Pierre "delroth" Bourdon <[email protected]>
Software Engineer @ Z?rich, Switzerland
http://code.delroth.net/
On Mon, Jan 6, 2014 at 12:23 PM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2013-12-31 at 05:24 +0100, Pierre Bourdon wrote:
>> Hello linux-wireless,
>>
>> I'm a developer of libdrc, a project that allows Linux computers to
>> control a Wii U GamePad. Because of how the device operates, our
>> library needs to be able to read the TSF value of the access point
>> device from userland.
>>
>> We currently have a hacky patch that works for our use cases, but it
>> would be a lot more convenient if that feature could be upstreamed.
>> What would be the best way to proceed?
>
> That patch ... let's say I think "hacky" is almost lauding it. :)
>
> sysfs is a really bad place for this too, no other wireless APIs use
> sysfs.
What do you recommend as the best place to export this kind of information?
--
Pierre "delroth" Bourdon <[email protected]>
Software Engineer @ Z?rich, Switzerland
http://code.delroth.net/
Hi
On Tue, Jan 14, 2014 at 9:26 AM, Kalle Valo <[email protected]> wrote:
> David Herrmann <[email protected]> writes:
>
>>> Either nl80211 or debugfs. Maybe debugfs is better because this is more
>>> or less a hack?
>>
>> It's supposed to be a real interface used to calculate timestamps for
>> mpeg streams, iirc. So debugfs is no option here.
>
> And how is sysfs any better? If you use sysfs right now I don't see why
> debugfs would be any worse. You just need to check from your application
> that it's mounted and find the location.
We don't guarantee debugfs API stability across kernel-releases. At
least my experience is that debugfs is highly discouraged to be used
as stable API interface, except for debug-applications. Anyhow, if you
have different rules in ./net/mac80211, feel free to put it there. At
least it's better than having no interface at all.
Thanks
David
Hi Pierre
On Fri, Jan 3, 2014 at 2:07 AM, Pierre Bourdon <[email protected]> wrote:
> On Tue, Dec 31, 2013 at 5:24 AM, Pierre Bourdon <[email protected]> wrote:
>> Hello linux-wireless,
>>
>> I'm a developer of libdrc, a project that allows Linux computers to
>> control a Wii U GamePad. Because of how the device operates, our
>> library needs to be able to read the TSF value of the access point
>> device from userland.
>>
>> We currently have a hacky patch that works for our use cases, but it
>> would be a lot more convenient if that feature could be upstreamed.
>> What would be the best way to proceed?
>>
>> Our current patch:
>> https://bitbucket.org/memahaxx/drc-mac80211/commits/4a9823cf2a6733bc15a05cffaebd8850d07451a7
>
> To clarify: I have 0 experience developing "clean" stuff for the Linux
> driver (only hacky patches). A few simple questions that I have in
> order to make this patch more useful:
Usual procedure is to send the patch via git-send-email and people
will comment on it. Even if it's a hack, please send the patch. And
you might wanna CC the maintainers of the affected trees.
> * Is there some kind of "threshold" for features like this to be
> accepted upstream? How likely is it that this feature will get merged
> in the end?
If there's a use-case, it is very likely get merged (unless another
more appropriate API comes up). So just keep pushing on it, nobody
minds if you resend the patch if it was unanswered for a week.
> * Is there any framework for exporting data from mac80211 drivers to a
> /sys or /proc file? There is code that exports data to debugfs, but
> that is usually not mounted by default or enabled by distributions.
> Our patch currently uses a /sys file, but I think nothing else in
> mac80211 does anything like that so far.
>From inside of mac80211 we don't control any sysfs attributes, yet.
Furthermore, device_create_file() is usually racy with device_add(),
so you really should create global attributes via the .attr field of
devices (or classes/types). See net/wireless/sysfs.c.
But you probably don't want to introduce a reverse dependency on
mac80211 from net/wireless/, I am not sure what to do here.. others
should know better.
> * Should integer values be exported as human-readable ASCII base 10
> numbers in proc/sys files or is exporting the raw bytes as our patch
> currently does acceptable?
sysfs must be human-readable and 1-value-per-file. See
Documentation/filesystems/sysfs.txt.
So if there's no strong reason to change that, I'd say convert it to
ASCII and you're fine. You can choose a suitable base yourself, but
base-10 is a good default.
Regarding your patch:
- please adjust your coding-style to Documentation/CodingStyle
- The drv_add_interface() hack looks really weird.. are you sure you
don't wanna bail out instead?
Thanks
David
David Herrmann <[email protected]> writes:
>> Either nl80211 or debugfs. Maybe debugfs is better because this is more
>> or less a hack?
>
> It's supposed to be a real interface used to calculate timestamps for
> mpeg streams, iirc. So debugfs is no option here.
And how is sysfs any better? If you use sysfs right now I don't see why
debugfs would be any worse. You just need to check from your application
that it's mounted and find the location.
--
Kalle Valo
On Tue, Dec 31, 2013 at 5:24 AM, Pierre Bourdon <[email protected]> wrote:
> Hello linux-wireless,
>
> I'm a developer of libdrc, a project that allows Linux computers to
> control a Wii U GamePad. Because of how the device operates, our
> library needs to be able to read the TSF value of the access point
> device from userland.
>
> We currently have a hacky patch that works for our use cases, but it
> would be a lot more convenient if that feature could be upstreamed.
> What would be the best way to proceed?
>
> Our current patch:
> https://bitbucket.org/memahaxx/drc-mac80211/commits/4a9823cf2a6733bc15a05cffaebd8850d07451a7
To clarify: I have 0 experience developing "clean" stuff for the Linux
driver (only hacky patches). A few simple questions that I have in
order to make this patch more useful:
* Is there some kind of "threshold" for features like this to be
accepted upstream? How likely is it that this feature will get merged
in the end?
* Is there any framework for exporting data from mac80211 drivers to a
/sys or /proc file? There is code that exports data to debugfs, but
that is usually not mounted by default or enabled by distributions.
Our patch currently uses a /sys file, but I think nothing else in
mac80211 does anything like that so far.
* Should integer values be exported as human-readable ASCII base 10
numbers in proc/sys files or is exporting the raw bytes as our patch
currently does acceptable?
Thanks,
--
Pierre "delroth" Bourdon <[email protected]>
Software Engineer @ Z?rich, Switzerland
http://code.delroth.net/
On Tue, 2013-12-31 at 05:24 +0100, Pierre Bourdon wrote:
> Hello linux-wireless,
>
> I'm a developer of libdrc, a project that allows Linux computers to
> control a Wii U GamePad. Because of how the device operates, our
> library needs to be able to read the TSF value of the access point
> device from userland.
>
> We currently have a hacky patch that works for our use cases, but it
> would be a lot more convenient if that feature could be upstreamed.
> What would be the best way to proceed?
That patch ... let's say I think "hacky" is almost lauding it. :)
sysfs is a really bad place for this too, no other wireless APIs use
sysfs.
johannes
Hi
On Tue, Jan 14, 2014 at 7:36 AM, Kalle Valo <[email protected]> wrote:
> Pierre Bourdon <[email protected]> writes:
>
>> On Mon, Jan 6, 2014 at 12:23 PM, Johannes Berg
>> <[email protected]> wrote:
>>> On Tue, 2013-12-31 at 05:24 +0100, Pierre Bourdon wrote:
>>>> Hello linux-wireless,
>>>>
>>>> I'm a developer of libdrc, a project that allows Linux computers to
>>>> control a Wii U GamePad. Because of how the device operates, our
>>>> library needs to be able to read the TSF value of the access point
>>>> device from userland.
>>>>
>>>> We currently have a hacky patch that works for our use cases, but it
>>>> would be a lot more convenient if that feature could be upstreamed.
>>>> What would be the best way to proceed?
>>>
>>> That patch ... let's say I think "hacky" is almost lauding it. :)
>>>
>>> sysfs is a really bad place for this too, no other wireless APIs use
>>> sysfs.
>>
>> What do you recommend as the best place to export this kind of information?
>
> Either nl80211 or debugfs. Maybe debugfs is better because this is more
> or less a hack?
It's supposed to be a real interface used to calculate timestamps for
mpeg streams, iirc. So debugfs is no option here.
Thanks
David
Pierre Bourdon <[email protected]> writes:
> On Mon, Jan 6, 2014 at 12:23 PM, Johannes Berg
> <[email protected]> wrote:
>> On Tue, 2013-12-31 at 05:24 +0100, Pierre Bourdon wrote:
>>> Hello linux-wireless,
>>>
>>> I'm a developer of libdrc, a project that allows Linux computers to
>>> control a Wii U GamePad. Because of how the device operates, our
>>> library needs to be able to read the TSF value of the access point
>>> device from userland.
>>>
>>> We currently have a hacky patch that works for our use cases, but it
>>> would be a lot more convenient if that feature could be upstreamed.
>>> What would be the best way to proceed?
>>
>> That patch ... let's say I think "hacky" is almost lauding it. :)
>>
>> sysfs is a really bad place for this too, no other wireless APIs use
>> sysfs.
>
> What do you recommend as the best place to export this kind of information?
Either nl80211 or debugfs. Maybe debugfs is better because this is more
or less a hack?
--
Kalle Valo