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
