Re: WCONF, netlink based WE replacement.
On Fri, Jan 13, 2006 at 02:15:03PM +0100, Thomas Graf wrote: * Michael Buesch [EMAIL PROTECTED] 2006-01-12 18:24 This is an attempt to rewrite the Wireless Extensions userspace API, using netlink sockets. There should also be a notification API, to inform userspace for changes (config changes, state changes, etc). It is not implemented, yet. I'll only comment on the netlink bits and leave the rest to others. I'd highly recommend the use of attributes instead of fixed message structures to allow the interface to be flexible to extensions while staying binary compatible. I can only second Thomas' suggestion. The power and flexibility of the use of netlink is only really unveiled if you use attributes. This way you can easily extend your data structures later on without breaking compatibility, etc. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpSNFb09iVlx.pgp Description: PGP signature
Re: WCONF, netlink based WE replacement.
Michael Buesch wrote: We also have a function to burn (and read) the SPROM though a private handler, atm. I consider this a very device specific task, which does not really need a standard API. Noone will ever reflash the SPROM, if he has no good good good reasons. ;) The idea of an (WE independent) standard API for flashing is not that bad, there are quite a few devices that support it. That is not implemented. a magic dest string all could be used instead of the specific interface. Wouldn't it mean all interfaces on all wireless cards? Yes. Need to think about it... It's too late now :P And what in the case you have some interface named all? Simply disallow this special case. :P The all doesn't IMHO server the purpose. You will virtualy never want to set something on all devices. You will want to set it on the minimal subset that shares the resource instead, and want (to be able) to know the subset Feyd - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
John W. Linville wrote: What is WCONF_CMD_NICK for? Just for users convenience, like the nick in WE. Is it really useful? No :) Is the point here to support all current WEXT functionality? It probably should be. For compatibility, we will likely need code to translate the WEXT ioctls to the netlink stuff. The ioctl to change the nickname will need someplace to go. So, useless or not, I think the WCONF_CMD_NICK is appropriate. I have never used this myself and don't know anyone who did.. The compat ioctl can simply return unimplemented. Feyd - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Fri, 2006-01-13 at 10:25 +0100, Feyd wrote: The all doesn't IMHO server the purpose. You will virtualy never want to set something on all devices. You will want to set it on the minimal subset that shares the resource instead, and want (to be able) to know the subset Ack. This needs to be handled in the API. (i.e. you need to be able to get a list of virtual devices sharing the channel etc.) Or, come to think of it, how about specifying this in some sort of tree? A virtual device would say have a list of properties that can be manipulated on it, for example a STA device: * essid * bssid * ... and for the others, it'd have a parent pointer which you somehow follow (needs API too to get all childs of a parent) johannes signature.asc Description: This is a digitally signed message part
Re: WCONF, netlink based WE replacement.
* Michael Buesch [EMAIL PROTECTED] 2006-01-12 18:24 This is an attempt to rewrite the Wireless Extensions userspace API, using netlink sockets. There should also be a notification API, to inform userspace for changes (config changes, state changes, etc). It is not implemented, yet. I'll only comment on the netlink bits and leave the rest to others. I'd highly recommend the use of attributes instead of fixed message structures to allow the interface to be flexible to extensions while staying binary compatible. Another idea might be to use the new generic netlink family to make things a bit easier to use. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Thu, 12 Jan 2006 18:24:02 +0100 Michael Buesch [EMAIL PROTECTED] wrote: This is an attempt to rewrite the Wireless Extensions userspace API, using netlink sockets. There should also be a notification API, to inform userspace for changes (config changes, state changes, etc). It is not implemented, yet. This is against the devicescape stack. This patch is not to be used, but only to be commented on. ;) Basically I would like comments on the API definition in wconf.h 1. You will need more documentation, eventually in Documentation directory. 2. Is there 1:1 relationship between ieee80211_device and net_device or N net_devices per ieee80211_device? 3. Don't put a version number on the protocol messages. The way to us netlink is to us Type Length Variable structures. And write the code to ignore unknown types. Once you decide on a particular Type then it has to be frozen for ABI compatibility. The version numbering in the WE API is part of the problem 4. What about non-ieee80211 devices? With the growth of (mostly proprietary) cell phone carrier wireless, you don't want to shut out that. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Pá 13-01-06 09:55:33, Stephen Hemminger wrote: On Thu, 12 Jan 2006 18:24:02 +0100 4. What about non-ieee80211 devices? With the growth of (mostly proprietary) cell phone carrier wireless, you don't want to shut out that. Don't mix it here. Mobile phones normally talk using AT interface, modem-like. Pavel -- Thanks, Sharp! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Sat, 2006-01-14 at 00:23 +0100, Pavel Machek wrote: On Pá 13-01-06 09:55:33, Stephen Hemminger wrote: On Thu, 12 Jan 2006 18:24:02 +0100 4. What about non-ieee80211 devices? With the growth of (mostly proprietary) cell phone carrier wireless, you don't want to shut out that. Don't mix it here. Mobile phones normally talk using AT interface, modem-like. I think he was referring to possible cell phone hardware when linux is running on the phone, not a full phone connected to linux. johannes signature.asc Description: This is a digitally signed message part
Re: WCONF, netlink based WE replacement.
[removed lkml]
On Thu, 12 Jan 2006 18:24:02 +0100, Michael Buesch wrote:
[...]
--- linux-2.6.15-ds060105.orig/include/net/ieee80211.h2006-01-08
02:10:46.0 +0100
+++ linux-2.6.15-ds060105/include/net/ieee80211.h 2006-01-09
16:22:59.0 +0100
[...]
+struct ieee80211_device {
+ /* Device name string. Usually wlanX. */
+ __u8 name[IFNAMSIZ + 1];
+ /* Hardware data. */
+ struct ieee80211_hw *hw;
+ /* Wireless Configuration data. */
+ struct wconf_device *wconf;
+ struct net_device *dev;/*TODO: We want to get rid of the master
net_device
+ and use ieee80211_device instead. */
+};
This ieee80211_device structure is redundant, wconf_device etc. should
be in ieee80211_hw.
--- linux-2.6.15-ds060105.orig/include/net/wconf.h1970-01-01
01:00:00.0 +0100
+++ linux-2.6.15-ds060105/include/net/wconf.h 2006-01-11 21:53:55.0
+0100
[...]
+enum {
+ WCONF_CMD_NAME,
+ WCONF_CMD_NICK,
What is WCONF_CMD_NICK for?
+ WCONF_CMD_MODE,
+ WCONF_CMD_CHANNEL,
+ WCONF_CMD_SENSITIVITY,
+ //TODO
+ WCONF_NR_STANDARD, /* Number of standard commands. */
+ WCONF_CMD_FIRSTPRIV = 0x0001,
+ WCONF_CMD_LASTPRIV = 0x,
+};
Do we really need private commands?
+enum {
+ WCONF_MODE_AUTO,/* Let the driver decides */
AUTO mode has no sense.
+ WCONF_MODE_ADHOC, /* Single cell network */
+ WCONF_MODE_INFRA, /* Multi cell network, roaming, ... */
+ WCONF_MODE_MASTER, /* Synchronisation master or Access Point */
+ WCONF_MODE_REPEAT, /* Wireless Repeater (forwarder) */
+ WCONF_MODE_SECOND, /* Secondary master/repeater (backup) */
+ WCONF_MODE_MONITOR, /* Passive monitor (listen only) */
+};
When we are creating a new API, couldn't we use names conforming to the
standard? I. e. AP instead of MASTER, WDS instead of REPEATER, etc.?
+struct wconf_cmd_channel {
+ /** Frequency in KHz, or channel number if 1000 */
+ __u32 freq;
+ __u8flags;
+#define WCONF_CHAN_AUTO (1 0)
+#define WCONF_CHAN_FIXED (1 1)
+};
Do we really want frequency to be set from userspace?
+/*** KERNEL API (Driver and internal) ***/
+
+/*TODO: Handler functions are currently not implemented. They must be hooked
up by the
+ * ieee80211 subsystem (and must be implemented as part of the
ieee80211 subsys).
+ * Where applicable, the drivers must re-hook the handler functions
(for hardware
+ * MAC for example).
+ */
I'm not sure here. When drivers are allowed to rehook handlers, there is
a possibility that handlers in different drivers won't behave in the
same way regarding to userspace. Maybe all calls should go through the
ieee80211 and there should be callbacks in ieee80211_hw designed for
cards with advanced firmware?
Also, I wasn't able to find out (perhaps I just didn't look carefully
enough) how you addressed the problem of commands that affect all of
interfaces vs. commands that affect just one interface.
Thanks,
--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Thursday 12 January 2006 19:08, you wrote:
[removed lkml]
On Thu, 12 Jan 2006 18:24:02 +0100, Michael Buesch wrote:
[...]
--- linux-2.6.15-ds060105.orig/include/net/ieee80211.h 2006-01-08
02:10:46.0 +0100
+++ linux-2.6.15-ds060105/include/net/ieee80211.h 2006-01-09
16:22:59.0 +0100
[...]
+struct ieee80211_device {
+ /* Device name string. Usually wlanX. */
+ __u8 name[IFNAMSIZ + 1];
+ /* Hardware data. */
+ struct ieee80211_hw *hw;
+ /* Wireless Configuration data. */
+ struct wconf_device *wconf;
+ struct net_device *dev;/*TODO: We want to get rid of the master
net_device
+ and use ieee80211_device instead. */
+};
This ieee80211_device structure is redundant, wconf_device etc. should
be in ieee80211_hw.
Well, ieee80211_device is basically a hackish replacement for the
currently used net_device, which we use for the master device.
See the comment.
This struct is really only to get the code compiling and to
do some testing. ;) It is not my intention to leave it in
the final API.
--- linux-2.6.15-ds060105.orig/include/net/wconf.h 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.15-ds060105/include/net/wconf.h 2006-01-11
21:53:55.0 +0100
[...]
+enum {
+ WCONF_CMD_NAME,
+ WCONF_CMD_NICK,
What is WCONF_CMD_NICK for?
Just for users convenience, like the nick in WE.
+ WCONF_CMD_MODE,
+ WCONF_CMD_CHANNEL,
+ WCONF_CMD_SENSITIVITY,
+ //TODO
+ WCONF_NR_STANDARD, /* Number of standard commands. */
+ WCONF_CMD_FIRSTPRIV = 0x0001,
+ WCONF_CMD_LASTPRIV = 0x,
+};
Do we really need private commands?
yes, I _really_ think so.
The bcm43xx driver has some device specific stuff to configure
for example.
+enum {
+ WCONF_MODE_AUTO,/* Let the driver decides */
AUTO mode has no sense.
Agreed. I just copied it from WE ;)
+ WCONF_MODE_ADHOC, /* Single cell network */
+ WCONF_MODE_INFRA, /* Multi cell network, roaming, ... */
+ WCONF_MODE_MASTER, /* Synchronisation master or Access Point */
+ WCONF_MODE_REPEAT, /* Wireless Repeater (forwarder) */
+ WCONF_MODE_SECOND, /* Secondary master/repeater (backup) */
+ WCONF_MODE_MONITOR, /* Passive monitor (listen only) */
+};
When we are creating a new API, couldn't we use names conforming to the
standard? I. e. AP instead of MASTER, WDS instead of REPEATER, etc.?
Yes, that's a good suggestion.
+struct wconf_cmd_channel {
+ /** Frequency in KHz, or channel number if 1000 */
+ __u32 freq;
+ __u8flags;
+#define WCONF_CHAN_AUTO(1 0)
+#define WCONF_CHAN_FIXED (1 1)
+};
Do we really want frequency to be set from userspace?
Yes, I think so. The user must be able to switch channels
manually (frequency == channel).
+/*** KERNEL API (Driver and internal) ***/
+
+/*TODO: Handler functions are currently not implemented. They must be
hooked up by the
+ * ieee80211 subsystem (and must be implemented as part of the
ieee80211 subsys).
+ * Where applicable, the drivers must re-hook the handler functions
(for hardware
+ * MAC for example).
+ */
I'm not sure here. When drivers are allowed to rehook handlers, there is
a possibility that handlers in different drivers won't behave in the
same way regarding to userspace. Maybe all calls should go through the
ieee80211 and there should be callbacks in ieee80211_hw designed for
cards with advanced firmware?
This is supposed to be a well-defined API
and a different behaviour is simply considered a bug.
I don't see how you can reduce the possibility of such bugs
by doing callbacks.
My point is: I think of simple commands which do one thing
at a time. I do not want to implement such beasts like IWENCODEEXT
in the first place, which make misbehaviour by slightly different
implementations easily possible.
If we have one command for each task, it is easily possible
to get them right. It is also much easier to implement.
If we have a WCONF_CMD_KEY and a corresponding struct:
struct wconf_cmd_key {
__u8 index;
__u8 key[LEN];
};
there is not much to get wrong. Especially if it is documented
very well.
The current encryption algorithms (WEP, WPA, etc..) would be set
previously through some seperate WCONF_CMD_CRYPTALG or something
like that.
Also, I wasn't able to find out (perhaps I just didn't look carefully
enough) how you addressed the problem of commands that affect all of
interfaces vs. commands that affect just one interface.
That is not implemented.
a magic dest string all could be used instead
of the specific interface.
We also need more global calls to wconf, like
a user query for a list of all available interfaces, etc..
--
Greetings Michael.
pgpz7hiAHQHcu.pgp
Description: PGP signature
Re: WCONF, netlink based WE replacement.
On Thu, 12 Jan 2006 19:55:39 +0100, Michael Buesch wrote:
This ieee80211_device structure is redundant, wconf_device etc. should
be in ieee80211_hw.
Well, ieee80211_device is basically a hackish replacement for the
currently used net_device, which we use for the master device.
See the comment.
Master net_device should be replaced by ieee80211_hw.
What is WCONF_CMD_NICK for?
Just for users convenience, like the nick in WE.
Is it really useful? We don't have anything like this for e. g. Ethernet
devices.
Do we really need private commands?
yes, I _really_ think so.
The bcm43xx driver has some device specific stuff to configure
for example.
I don't know what is that stuff, so I can be wrong (probably some
clarification will help, if this won't take you much time). But if it is
something at least theoretically general (e. g. your card is the only
one implementing that command but it is mentioned in the standard), it
should be implemented in ieee80211. Real device-specific stuff (like
firmware flashing) can be done through sysfs then.
Do we really want frequency to be set from userspace?
Yes, I think so. The user must be able to switch channels
manually (frequency == channel).
I didn't mean channels, just frequencies. To be conformal with standards
and regulations, we can allow specific frequencies only. Those
frequencies are unambiguously mapped to channels anyway (you have to
specify a band of course). So I see no point in specifying frequencies
from userspace, channels should be enough.
This is supposed to be a well-defined API
and a different behaviour is simply considered a bug.
I don't see how you can reduce the possibility of such bugs
by doing callbacks.
My point is: I think of simple commands which do one thing
at a time. I do not want to implement such beasts like IWENCODEEXT
in the first place, which make misbehaviour by slightly different
implementations easily possible.
If we have one command for each task, it is easily possible
to get them right. It is also much easier to implement.
If we have a WCONF_CMD_KEY and a corresponding struct:
struct wconf_cmd_key {
__u8 index;
__u8 key[LEN];
};
there is not much to get wrong. Especially if it is documented
very well.
The current encryption algorithms (WEP, WPA, etc..) would be set
previously through some seperate WCONF_CMD_CRYPTALG or something
like that.
Ok.
That is not implemented.
a magic dest string all could be used instead
of the specific interface.
Wouldn't it mean all interfaces on all wireless cards? And what in the
case you have some interface named all?
We also need more global calls to wconf, like
a user query for a list of all available interfaces, etc..
It can be determined from sysfs, do we really need to implement it as a
netlink command too?
--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Thursday 12 January 2006 20:43, you wrote:
On Thu, 12 Jan 2006 19:55:39 +0100, Michael Buesch wrote:
This ieee80211_device structure is redundant, wconf_device etc. should
be in ieee80211_hw.
Well, ieee80211_device is basically a hackish replacement for the
currently used net_device, which we use for the master device.
See the comment.
Master net_device should be replaced by ieee80211_hw.
Whatever.
What is WCONF_CMD_NICK for?
Just for users convenience, like the nick in WE.
Is it really useful?
No :)
We don't have anything like this for e. g. Ethernet
devices.
Do we really need private commands?
yes, I _really_ think so.
The bcm43xx driver has some device specific stuff to configure
for example.
I don't know what is that stuff, so I can be wrong (probably some
clarification will help, if this won't take you much time). But if it is
something at least theoretically general (e. g. your card is the only
one implementing that command but it is mentioned in the standard), it
should be implemented in ieee80211.
Well, I don't really want to list specific stuff here,
as it is a general design decision.
I really don't think we should remove the private interface and
force drivers to use yet another incompatible new API _if_ they
have the need for such a private configuration task.
Real device-specific stuff (like
firmware flashing) can be done through sysfs then.
Why this extra complexity?
One think I'd like to see (well, keep) is that a wireless device
can be configured in a whole through one well known
interface. Including private card configuration.
We currently set the interference mitigation mode through
a private WE. We can argue, if the Radio Interference
Mitigation conf should be implemented as a standard command... .
We also set a few other things (don't remember them now) and I know
that there are still lots of finetuning parameters hardcoded, which
could be made available through this private interface.
We also have a function to burn (and read) the SPROM though a
private handler, atm. I consider this a very device specific task,
which does not really need a standard API. Noone will ever reflash
the SPROM, if he has no good good good reasons. ;)
Imagine device-specific firmware tuning parameters.
Do we really want frequency to be set from userspace?
Yes, I think so. The user must be able to switch channels
manually (frequency == channel).
I didn't mean channels, just frequencies. To be conformal with standards
and regulations, we can allow specific frequencies only. Those
frequencies are unambiguously mapped to channels anyway (you have to
specify a band of course). So I see no point in specifying frequencies
from userspace, channels should be enough.
Ah, I understand what you mean and I agree.
I thought there was a reason for freq selection in WE. Does
not seem so, though... .
This is supposed to be a well-defined API
and a different behaviour is simply considered a bug.
I don't see how you can reduce the possibility of such bugs
by doing callbacks.
My point is: I think of simple commands which do one thing
at a time. I do not want to implement such beasts like IWENCODEEXT
in the first place, which make misbehaviour by slightly different
implementations easily possible.
If we have one command for each task, it is easily possible
to get them right. It is also much easier to implement.
If we have a WCONF_CMD_KEY and a corresponding struct:
struct wconf_cmd_key {
__u8 index;
__u8 key[LEN];
};
there is not much to get wrong. Especially if it is documented
very well.
The current encryption algorithms (WEP, WPA, etc..) would be set
previously through some seperate WCONF_CMD_CRYPTALG or something
like that.
Ok.
That is not implemented.
a magic dest string all could be used instead
of the specific interface.
Wouldn't it mean all interfaces on all wireless cards?
Yes. Need to think about it... It's too late now :P
And what in the
case you have some interface named all?
Simply disallow this special case. :P
We also need more global calls to wconf, like
a user query for a list of all available interfaces, etc..
It can be determined from sysfs, do we really need to implement it as a
netlink command too?
Well, I think at least a simple listing of all available
interfaces should be implemented through netlink, to
ease the userspace program a lot. Otherwise we would always
have to deal with two APIs (sysfs and netlink) to get the simplest
stuff done.
I don't think there is a need for another device-unbound function.
Anyone?
--
Greetings Michael.
pgpcjA5YRm2mO.pgp
Description: PGP signature
Re: WCONF, netlink based WE replacement.
On Thu, Jan 12, 2006 at 09:04:24PM +0100, Michael Buesch wrote: On Thursday 12 January 2006 20:43, you wrote: On Thu, 12 Jan 2006 19:55:39 +0100, Michael Buesch wrote: This ieee80211_device structure is redundant, wconf_device etc. should be in ieee80211_hw. Well, ieee80211_device is basically a hackish replacement for the currently used net_device, which we use for the master device. See the comment. Master net_device should be replaced by ieee80211_hw. Whatever. What is WCONF_CMD_NICK for? Just for users convenience, like the nick in WE. Is it really useful? No :) Is the point here to support all current WEXT functionality? It probably should be. For compatibility, we will likely need code to translate the WEXT ioctls to the netlink stuff. The ioctl to change the nickname will need someplace to go. So, useless or not, I think the WCONF_CMD_NICK is appropriate. We don't have anything like this for e. g. Ethernet devices. Do we really need private commands? yes, I _really_ think so. The bcm43xx driver has some device specific stuff to configure for example. I don't know what is that stuff, so I can be wrong (probably some clarification will help, if this won't take you much time). But if it is something at least theoretically general (e. g. your card is the only one implementing that command but it is mentioned in the standard), it should be implemented in ieee80211. Well, I don't really want to list specific stuff here, as it is a general design decision. I really don't think we should remove the private interface and force drivers to use yet another incompatible new API _if_ they have the need for such a private configuration task. I sympathize with the need for side configuration and wanting to avoid using multiple APIs. Still, what is the fundamental difference between private netlink messages and private ioctls? If it were coded as an ioctl, it would be generally derided. If you can use sysfs for any necessary private configuration then I think that is what is needed. You will need a custom tool for your custom configuration anyway (unless you plan to pollute iproute2 or whatever), so using a different API shouldn't be an undue burden. If sysfs just doesn't meet the needs and it just has to be netlink, then perhaps we can entertain the private netlink messages later? For now, I would prefer not to endorse the idea of using them. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Thursday 12 January 2006 22:00, you wrote: On Thu, Jan 12, 2006 at 09:04:24PM +0100, Michael Buesch wrote: On Thursday 12 January 2006 20:43, you wrote: On Thu, 12 Jan 2006 19:55:39 +0100, Michael Buesch wrote: This ieee80211_device structure is redundant, wconf_device etc. should be in ieee80211_hw. Well, ieee80211_device is basically a hackish replacement for the currently used net_device, which we use for the master device. See the comment. Master net_device should be replaced by ieee80211_hw. Whatever. What is WCONF_CMD_NICK for? Just for users convenience, like the nick in WE. Is it really useful? No :) Is the point here to support all current WEXT functionality? Yes, plus all additionally stuff, which we need to figure out. ;) It probably should be. For compatibility, we will likely need code to translate the WEXT ioctls to the netlink stuff. The ioctl to change the nickname will need someplace to go. So, useless or not, I think the WCONF_CMD_NICK is appropriate. Well, it is nice to have a human readable name for a device. Althought kernel space is maybe a suboptimal place to implement such stuff. We don't have anything like this for e. g. Ethernet devices. Do we really need private commands? yes, I _really_ think so. The bcm43xx driver has some device specific stuff to configure for example. I don't know what is that stuff, so I can be wrong (probably some clarification will help, if this won't take you much time). But if it is something at least theoretically general (e. g. your card is the only one implementing that command but it is mentioned in the standard), it should be implemented in ieee80211. Well, I don't really want to list specific stuff here, as it is a general design decision. I really don't think we should remove the private interface and force drivers to use yet another incompatible new API _if_ they have the need for such a private configuration task. I sympathize with the need for side configuration and wanting to avoid using multiple APIs. Still, what is the fundamental difference between private netlink messages and private ioctls? If it were coded as an ioctl, it would be generally derided. The difference is that we want a, yet to be written, userspace counterpart of the API. Do we really want to deal with ioctls in the program managing the private handlers? I don't think so. The private netlink command mechanism is very lean and has basically additional cost, as it is built on top of the standard message mechanism. (It only needs an additional generic struct in the message union. I forgot to add it) If you can use sysfs for any necessary private configuration then I think that is what is needed. You will need a custom tool for your custom configuration anyway (unless you plan to pollute iproute2 or whatever), so using a different API shouldn't be an undue burden. If sysfs just doesn't meet the needs and it just has to be netlink, then perhaps we can entertain the private netlink messages later? For now, I would prefer not to endorse the idea of using them. Ok, the private messages are of very low priority and were only meant as an additional cookie (as they are easily implemented on top of the standard handlers). So the next step would be to clone WE functionality, but avoiding such (IMHO ugly) stuff like IWENCODE(EXT)? -- Greetings Michael. pgpBm1Oo5NsVK.pgp Description: PGP signature
Re: WCONF, netlink based WE replacement.
On Thu, Jan 12, 2006 at 08:43:06PM +0100, Jiri Benc wrote: I didn't mean channels, just frequencies. To be conformal with standards and regulations, we can allow specific frequencies only. Those frequencies are unambiguously mapped to channels anyway (you have to specify a band of course). So I see no point in specifying frequencies from userspace, channels should be enough. While frequencies map cleanly to channels, the other direction is more difficult, as different bands have the same channel numbers. This isn't theoretical -- 802.11j's lower 5.0Ghz band uses channels 8-16, directly clashing with 802.11-1999's 2.4GHz use of channels 8-14. (That's before we even begin to start talking about 802.11j's concept of both 20MHz and 10MHz-wide channels..) It makes more sense to specify the frequency, as there is no ambiguity there at all (and saves us having to specify a [band,channel] pair each time) -- it's trivial to map this into a prettier end-user representation, but that should happen in userland, and not be hardwired into the underlying API/ABI or kernel itself. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpkcnVp0CUFB.pgp Description: PGP signature
