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
