Exporting the TSF to userland

Exporting the TSF to userland

[Pierre Bourdon]

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 <delroth@gmail.com>
Software Engineer @ Zürich, Switzerland
http://code.delroth.net/

Re: Exporting the TSF to userland

[Kalle Valo]

Pierre Bourdon <delroth@gmail.com> 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

Re: Exporting the TSF to userland

[Pierre Bourdon]

On Tue, Dec 31, 2013 at 9:23 AM, Kalle Valo <kvalo@adurom.com> wrote:
> Pierre Bourdon <delroth@gmail.com> 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 <delroth@gmail.com>
Software Engineer @ Zürich, Switzerland
http://code.delroth.net/

Re: Exporting the TSF to userland

[Pierre Bourdon]

On Tue, Dec 31, 2013 at 5:24 AM, Pierre Bourdon <delroth@gmail.com> 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 <delroth@gmail.com>
Software Engineer @ Zürich, Switzerland
http://code.delroth.net/

Re: Exporting the TSF to userland

[David Herrmann]

Hi Pierre

On Fri, Jan 3, 2014 at 2:07 AM, Pierre Bourdon <delroth@gmail.com> wrote:
> On Tue, Dec 31, 2013 at 5:24 AM, Pierre Bourdon <delroth@gmail.com> 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

Re: Exporting the TSF to userland

[Johannes Berg]

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

Re: Exporting the TSF to userland

[Pierre Bourdon]

On Mon, Jan 6, 2014 at 12:23 PM, Johannes Berg
<johannes@sipsolutions.net> 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 <delroth@gmail.com>
Software Engineer @ Zürich, Switzerland
http://code.delroth.net/

Re: Exporting the TSF to userland

[Kalle Valo]

Pierre Bourdon <delroth@gmail.com> writes:

> On Mon, Jan 6, 2014 at 12:23 PM, Johannes Berg
> <johannes@sipsolutions.net> 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

Re: Exporting the TSF to userland

[David Herrmann]

Hi

On Tue, Jan 14, 2014 at 7:36 AM, Kalle Valo <kvalo@adurom.com> wrote:
> Pierre Bourdon <delroth@gmail.com> writes:
>
>> On Mon, Jan 6, 2014 at 12:23 PM, Johannes Berg
>> <johannes@sipsolutions.net> 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

Re: Exporting the TSF to userland

[Kalle Valo]

David Herrmann <dh.herrmann@gmail.com> 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

Re: Exporting the TSF to userland

[David Herrmann]

Hi

On Tue, Jan 14, 2014 at 9:26 AM, Kalle Valo <kvalo@adurom.com> wrote:
> David Herrmann <dh.herrmann@gmail.com> 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