Re: [Bcm43xx-dev] [Fwd: State of the Union: Wireless]

[Harald Welte <laforge@gnumonks.org>]

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)

Attachment: pgpsvnJ2tHAmA.pgp
Description: PGP signature