How to add custom configuration command for cfg80211 based driver.
For WEXT was private IOCtls (iwpriv).
What the recommended way for nl80211/cfg80211?
Private tool with private API on driver?
2013/1/14 Julian Calaby <[email protected]>:
> Hi Eugene,
>
> On Mon, Jan 14, 2013 at 9:01 PM, Eugene <[email protected]> wrote:
>> 2013/1/14 Kalle Valo <[email protected]>:
>>> Eugene <[email protected]> writes:
>>>
>>>> How to add custom configuration command for cfg80211 based driver.
>>>>
>>>> For WEXT was private IOCtls (iwpriv).
>>>>
>>>> What the recommended way for nl80211/cfg80211?
>>>
>>> Luckily private commands are now banned, it was such a mess. Now you add
>>> a new generic command to nl80211/cfg80211 so that all drivers can use
>>> it. The benefit is that the driver can be changed without any
>>> modifications to user space.
>>
>> That's really good benefit.
>> But as a disadvantage for that approach required changes for kernel,
>> which cannot be done real-time (insmod for example).
>
> How so? If you have some new mode or feature, you implement support
> for it in cfg80211 and (if needed) mac80211, tell userspace about it
> through nl80211, build a driver that indicates that it has support for
> this feature, then add or patch user-space utilities to make use of
> it.
Sure, at any time I can patch the framework {nl,cfg}80211.
But that is useful for feature, which can be reused by other drivers.
And for sure I'll go by that way if so.
>
>>> Only exceptions are NL80211_CMD_TESTMODE for low level factory/RF tests
>>> and debugfs for developer debugging purposes.
>>>
>>
>> Hmm...
>> That's good point for testing, but still unusable for production.
>
> debugfs is for exposing internal state which would be useful for
> debugging, e.g. register values, low level statistics, etc.
>
>> Why kernel do not support custom commands, like TESTMODE?
>
> The goal, as I understand it, is to work out a framework for how
> TESTMODE could be implemented in a unified manner across all the
> drivers for all hardware which supports it. I'm not sure that any real
> progress has been made.
>
>> The reason is to unify all drivers?
>
> Precisely. User space shouldn't have to do anything "special" for any
> particular driver.
>
> I should be able to swap from an Atheros card to an Intel card and,
> providing the Intel card supports the features I'm using, userspace
> should continue on without any significant configuration changes.
>
That is explain a lot.
>> But what about new (or proprietary) features, use kernel patches only?
>
> New features should be written into the wireless stack as I described above.
>
> Proprietary features ... well that's a tricky one. Unless there's a
> real compelling reason to do so, they're most likely going to be
> ignored unless other chipsets implement compatible features and a
> unified interface for utilising them can be figured out.
>
> Exactly what features are you wanting to implement?
Can be a lot... like custom bridging.
Of course each of them should be individually investigated.
But currently my question is common.
And I think, that I got all the answers.
Thanks to everybody.
>
> Thanks,
>
> --
> Julian Calaby
>
> Email: [email protected]
> Profile: http://www.google.com/profiles/julian.calaby/
> .Plan: http://sites.google.com/site/juliancalaby/
Hi Eugene,
Let's keep the discussion in linux-wireless so that everyone can participate.
Eugene <[email protected]> writes:
> Now I got the point.
Great!
> If the feature will be useful for community I'll post it for sure.
> Otherwise I'll use the custom wheel :)
I would like to be a bit extreme here. Even if you feel that some
feature isn't useful for the community I still recommend sending a small
RFC patch and see what kind of feedback you get. It doesn't take much of
your time and you never know what's the feedback until you send it, with
luck people might be actually interested about your feature! And most of
the time people send suggestions how to do it better.
Just keep the patches small, don't send any patch bombs and one feature
per patch. RFC patches don't need to be perfect as they are just to, as
the name implies, Request For Comments :)
--
Kalle Valo
Julian Calaby <[email protected]> writes:
>> Why kernel do not support custom commands, like TESTMODE?
>
> The goal, as I understand it, is to work out a framework for how
> TESTMODE could be implemented in a unified manner across all the
> drivers for all hardware which supports it. I'm not sure that any real
> progress has been made.
I personally think that will never work out. With testmode we are
talking about very low level features like RF registers, calibration, HW
testing etc. Stuff which is only run in a factory or by an RF engineer.
Finding a common interface for all HW designs is hard as they are so
different.
(Disclaimer: of course the above doesn't apply to high level features
related 802.11 and both cfg80211 and mac80211 are a great proof of that)
--
Kalle Valo
Hi Eugene,
On Mon, Jan 14, 2013 at 9:01 PM, Eugene <[email protected]> wrote:
> 2013/1/14 Kalle Valo <[email protected]>:
>> Eugene <[email protected]> writes:
>>
>>> How to add custom configuration command for cfg80211 based driver.
>>>
>>> For WEXT was private IOCtls (iwpriv).
>>>
>>> What the recommended way for nl80211/cfg80211?
>>
>> Luckily private commands are now banned, it was such a mess. Now you add
>> a new generic command to nl80211/cfg80211 so that all drivers can use
>> it. The benefit is that the driver can be changed without any
>> modifications to user space.
>
> That's really good benefit.
> But as a disadvantage for that approach required changes for kernel,
> which cannot be done real-time (insmod for example).
How so? If you have some new mode or feature, you implement support
for it in cfg80211 and (if needed) mac80211, tell userspace about it
through nl80211, build a driver that indicates that it has support for
this feature, then add or patch user-space utilities to make use of
it.
>> Only exceptions are NL80211_CMD_TESTMODE for low level factory/RF tests
>> and debugfs for developer debugging purposes.
>>
>
> Hmm...
> That's good point for testing, but still unusable for production.
debugfs is for exposing internal state which would be useful for
debugging, e.g. register values, low level statistics, etc.
> Why kernel do not support custom commands, like TESTMODE?
The goal, as I understand it, is to work out a framework for how
TESTMODE could be implemented in a unified manner across all the
drivers for all hardware which supports it. I'm not sure that any real
progress has been made.
> The reason is to unify all drivers?
Precisely. User space shouldn't have to do anything "special" for any
particular driver.
I should be able to swap from an Atheros card to an Intel card and,
providing the Intel card supports the features I'm using, userspace
should continue on without any significant configuration changes.
> But what about new (or proprietary) features, use kernel patches only?
New features should be written into the wireless stack as I described above.
Proprietary features ... well that's a tricky one. Unless there's a
real compelling reason to do so, they're most likely going to be
ignored unless other chipsets implement compatible features and a
unified interface for utilising them can be figured out.
Exactly what features are you wanting to implement?
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
Hi Kalle,
On Tue, Jan 15, 2013 at 12:38 AM, Kalle Valo <[email protected]> wrote:
> Julian Calaby <[email protected]> writes:
>
>>> Why kernel do not support custom commands, like TESTMODE?
>>
>> The goal, as I understand it, is to work out a framework for how
>> TESTMODE could be implemented in a unified manner across all the
>> drivers for all hardware which supports it. I'm not sure that any real
>> progress has been made.
>
> I personally think that will never work out. With testmode we are
> talking about very low level features like RF registers, calibration, HW
> testing etc. Stuff which is only run in a factory or by an RF engineer.
> Finding a common interface for all HW designs is hard as they are so
> different.
You're a lot closer to actual hardware than I am so you've probably
got a better idea of what can and can't be done. I was just parroting
what I heard about it last time it was mentioned.
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
2013/1/14 Kalle Valo <[email protected]>:
> Eugene <[email protected]> writes:
>
>> How to add custom configuration command for cfg80211 based driver.
>>
>> For WEXT was private IOCtls (iwpriv).
>>
>> What the recommended way for nl80211/cfg80211?
>
> Luckily private commands are now banned, it was such a mess. Now you add
> a new generic command to nl80211/cfg80211 so that all drivers can use
> it. The benefit is that the driver can be changed without any
> modifications to user space.
That's really good benefit.
But as a disadvantage for that approach required changes for kernel,
which cannot be done real-time (insmod for example).
>
> Only exceptions are NL80211_CMD_TESTMODE for low level factory/RF tests
> and debugfs for developer debugging purposes.
>
Hmm...
That's good point for testing, but still unusable for production.
> --
> Kalle Valo
Why kernel do not support custom commands, like TESTMODE?
The reason is to unify all drivers?
But what about new (or proprietary) features, use kernel patches only?
Eugene <[email protected]> writes:
> How to add custom configuration command for cfg80211 based driver.
>
> For WEXT was private IOCtls (iwpriv).
>
> What the recommended way for nl80211/cfg80211?
Luckily private commands are now banned, it was such a mess. Now you add
a new generic command to nl80211/cfg80211 so that all drivers can use
it. The benefit is that the driver can be changed without any
modifications to user space.
Only exceptions are NL80211_CMD_TESTMODE for low level factory/RF tests
and debugfs for developer debugging purposes.
--
Kalle Valo