Re: [PATCH v3] wireless: Supporting of IFLA_INFO_KIND rtnl attribute

2014-12-12 Thread Johannes Berg
On Wed, 2014-12-10 at 00:21 +0200, Vadim Kochan wrote:
 It allows to identify the wlan kind of device for the user application,

Applied,
 
 +static struct rtnl_link_ops wireless_link_ops __read_mostly = {
 + .kind = wlan,
 +};

but I've made this const. It only needs to be non-const (__read_mostly)
when used with rtnl_link_register() and friends.

johannes

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] wireless: Supporting of IFLA_INFO_KIND rtnl attribute

2014-12-10 Thread Marcel Holtmann
Hi Johannes,

 have we considered also exposing the mode of this netdev. So for
 example sta,ap,p2p-go,p2p-client etc. If we can send dynamic updates
 via RTNL, we could easily tell the networking management system what
 type of wireless device we have here. I am thinking about it like
 wlan/p2p-go etc. Or should this be better kept strictly to wlan.
 
 I certainly haven't considered this API at all :)
 That said, I'm not sure where it would be used, so I don't really know.
 
 And I am not sure RTNL would be capable of changing this kind strings
 at runtime anyway.
 
 Given the API (fixed constant string in a const struct that the netdev
 points to) it seems that it doesn't really support that, unless we
 change the internals to have a function to return the string or keep
 lots of copies of the struct and reassign them - neither seems very
 appealing.

if this is a constant string similar to DEVTYPE, the it should be just wlan 
and nothing else. If internal APIs require changing, then that could be done in 
addition to this patch.

Regards

Marcel

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] wireless: Supporting of IFLA_INFO_KIND rtnl attribute

2014-12-10 Thread Marcel Holtmann
Hi Vadim,

 It allows to identify the wlan kind of device for the user application,
 e.g.:
 
# ip -d link
 
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode 
 DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0
2: enp0s25: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast 
 state DOWN mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff promiscuity 0
3: wlp3s0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP 
 mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff promiscuity 0
wlan
 
 Signed-off-by: Vadim Kochan vadi...@gmail.com
 ---
 net/wireless/core.c | 6 ++
 1 file changed, 6 insertions(+)

for what its worth.

Acked-by: Marcel Holtmann mar...@holtmann.org

Regards

Marcel

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] wireless: Supporting of IFLA_INFO_KIND rtnl attribute

2014-12-09 Thread Marcel Holtmann
Hi Johannes,

 On Dec 9, 2014, at 23:21, Vadim Kochan vadi...@gmail.com wrote:
 
 It allows to identify the wlan kind of device for the user application,
 e.g.:
 
# ip -d link
 
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode 
 DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0
2: enp0s25: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast 
 state DOWN mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff promiscuity 0
3: wlp3s0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP 
 mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff promiscuity 0
wlan

have we considered also exposing the mode of this netdev. So for example 
sta,ap,p2p-go,p2p-client etc. If we can send dynamic updates via RTNL, we could 
easily tell the networking management system what type of wireless device we 
have here. I am thinking about it like wlan/p2p-go etc. Or should this be 
better kept strictly to wlan.

And I am not sure RTNL would be capable of changing this kind strings at 
runtime anyway.

Regards

Marcel

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] wireless: Supporting of IFLA_INFO_KIND rtnl attribute

2014-12-09 Thread vadim4j
On Wed, Dec 10, 2014 at 12:23:14AM +0100, Marcel Holtmann wrote:
 Hi Johannes,
 
  On Dec 9, 2014, at 23:21, Vadim Kochan vadi...@gmail.com wrote:
  
  It allows to identify the wlan kind of device for the user application,
  e.g.:
  
 # ip -d link
  
 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN mode 
  DEFAULT group default
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0
 2: enp0s25: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc 
  pfifo_fast state DOWN mode DEFAULT group default qlen 1000
 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff promiscuity 0
 3: wlp3s0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP 
  mode DEFAULT group default qlen 1000
 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff promiscuity 0
 wlan
 
 have we considered also exposing the mode of this netdev. So for example 
 sta,ap,p2p-go,p2p-client etc. If we can send dynamic updates via RTNL, we 
 could easily tell the networking management system what type of wireless 
 device we have here. I am thinking about it like wlan/p2p-go etc. Or should 
 this be better kept strictly to wlan.
 
 And I am not sure RTNL would be capable of changing this kind strings at 
 runtime anyway.
 
 Regards
 
 Marcel
 

May be better do not mix 2 things in one attribute?

Regards,
Vadim
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html