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
