On Thu, 19 Jan 2006 14:23:35 -0500
John W. Linville [EMAIL PROTECTED] wrote:
On Thu, Jan 19, 2006 at 08:03:43PM +0100, Stefan Rompf wrote:
Am Donnerstag 19 Januar 2006 16:56 schrieb John W. Linville:
The above represents my thinking on the issue. Ultimately the WiPHY
(aka radio)
Jouni Malinen wrote:
This may be the case with designs that do not provide anything else
than a simple interface for delivering and receiving frames. However,
the benefits--and I would be prepared to say even requirements--of
having a master device are extensive enough to use it with many wlan
On Thu, Jan 19, 2006 at 04:30:34PM +0100, feyd wrote:
The design that is rather agreed on proposes a master device that is
not netdev, is used for configuration of the shared resources (radio)
and for virtual devices creation, where the virtual devices cannot
switch mode.
The above
Am Donnerstag 19 Januar 2006 16:56 schrieb John W. Linville:
The above represents my thinking on the issue. Ultimately the WiPHY
(aka radio) device should be thought of as a new class of driver,
distinct from a netdev. If we have to reroute some infrastructure
(i.e. qdisc) to make that
On Thu, Jan 19, 2006 at 05:44:53PM +0100, Jiri Benc wrote:
On Thu, 19 Jan 2006 10:56:19 -0500, John W. Linville wrote:
The above represents my thinking on the issue. Ultimately the WiPHY
(aka radio) device should be thought of as a new class of driver,
distinct from a netdev. If we have
On Thu, Jan 19, 2006 at 08:03:43PM +0100, Stefan Rompf wrote:
Am Donnerstag 19 Januar 2006 16:56 schrieb John W. Linville:
The above represents my thinking on the issue. Ultimately the WiPHY
(aka radio) device should be thought of as a new class of driver,
distinct from a netdev. If we
On Thu, Jan 19, 2006 at 08:03:43PM +0100, Stefan Rompf wrote:
Am Donnerstag 19 Januar 2006 16:56 schrieb John W. Linville:
The above represents my thinking on the issue. Ultimately the WiPHY
(aka radio) device should be thought of as a new class of driver,
distinct from a netdev. If we
On Thu, Jan 19, 2006 at 04:30:34PM +0100, feyd wrote:
The point of the master not being netdev is to separate the two
functions it serves - configuration and master interface, as combining
them makes sense only for softmac devices.
The single queue that all the packets have to pass and can be
Jouni Malinen wrote:
On Tue, Jan 17, 2006 at 01:05:16PM +0100, Jiri Benc wrote:
On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote:
Actually, there is a use for the master device. It can be used to
monitor what is going on over the radio from all virtual APs/STAs, e.g.,
by running
On Wed, Jan 18, 2006 at 09:18:26AM +0100, Feyd wrote:
With fullmac devices the master interface makes no sense, it cannot be
used for neither the sniffing or QoS. The design where the master device
is something else than net_device is cleaner, it treats both soft/fullmac
devices equaly,
On Tue, Jan 17, 2006 at 01:05:16PM +0100, Jiri Benc wrote:
On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote:
Actually, there is a use for the master device. It can be used to
monitor what is going on over the radio from all virtual APs/STAs, e.g.,
by running Ethereal on it.
You
On Tue, Jan 17, 2006 at 02:55:31PM -0500, jamal wrote:
On Tue, 2006-17-01 at 11:42 -0800, Jouni Malinen wrote:
so if i understood correctly:
You have a master netdevice which underneath it has child netdevices?
I'm not sure what exactly child netdev means, but it sounds like
something that
Am Dienstag 17 Januar 2006 20:42 schrieb Jouni Malinen:
Sure, you can do it that way, too. However, this is not the only use. I
just remembered another one: QoS. Devicescape 802.11 code uses a qdisc
on the master interface to take care of determining which hardware TX
queue to use with WMM
On Tue, 17 Jan 2006 23:16:43 +0100
Stefan Rompf [EMAIL PROTECTED] wrote:
Am Dienstag 17 Januar 2006 20:42 schrieb Jouni Malinen:
Sure, you can do it that way, too. However, this is not the only use. I
just remembered another one: QoS. Devicescape 802.11 code uses a qdisc
on the master
14 matches
Mail list logo
