Messages in this thread | | | Date | Thu, 12 Jan 2006 15:20:42 +0100 | From | Harald Welte <> | Subject | Re: [Bcm43xx-dev] [Fwd: State of the Union: Wireless] |
| |
On Fri, Jan 06, 2006 at 01:46:15PM +0100, Patrick McHardy wrote: > Marcel Holtmann wrote: > > >>I just personally liked the idea of having a device node in /dev for > >>every existing hardware wlan card. Like we have device nodes for > >>other real hardware, too. It felt like a bit of a "unix way" to do > >>this to me. I don't say this is the way to go. > >>If a netlink socket is used (which is possible, for sure), we stay with > >>the old way of having no device node in /dev for networking devices. > >>That is ok. But that is really only an implementation detail (and for sure > >>a matter of taste). > >At the OLS last year, I think the consensus was to use netlink for all > >configuration task. However this was mainly driven by Harald Welte and > >he might be able to talk about the pros and cons of netlink versus a > >character device. > > I think the main advantages of netlink over a character device is its > flexible format, which is easily extendable, and multicast capability,
Especially the multicast capability is _extrmely_ handy, since you basically can have all sorts of dock-applets or monitoring applications that don't need to rely on polling device status but instead get multicast notifications of configuration changes.
Also, as a theoretical option, you could implement parts of the wireless subsystem outside of the kernel - esp. for the more extensive authentication/keying/rekeying functions.
A wireless configuration program would just speak netlink to a particular netlink multicast group. Whether or not the receiving functional entity is implemented in the kernel or in a wireless daemon in userspace could be completely transparent, as long as the protocol is the same.
-- - Harald Welte <laforge@gnumonks.org> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) [unhandled content-type:application/pgp-signature] | |