All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Buesch <mbuesch@freenet.de>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: jgarzik@pobox.com, bcm43xx-dev@lists.berlios.de,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Bcm43xx-dev] [Fwd: State of the Union: Wireless]
Date: Fri, 6 Jan 2006 12:45:55 +0100	[thread overview]
Message-ID: <200601061245.55978.mbuesch@freenet.de> (raw)
In-Reply-To: <1136547494.7429.72.camel@localhost>

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

On Friday 06 January 2006 12:38, you wrote:
> Hi Michael,
> 
> > How would the virtual interfaces look like? That is quite easy to answer.
> > They are net_devices, as they transfer data.
> > They should probaly _not_ be on top of the ethernet, as 80211 does not
> > have very much in common with ethernet. Basically they share the same
> > MAC address format. Does someone have another thing, which he thinks
> > is shared?
> > How would the master interface look like? A somewhat unusual idea came
> > up. Using a device node in /dev. So every wireless card in the system
> > would have a node in /dev associated (/dev/wlan0 for example).
> > A node for the master device would be ok, because no data is transferred
> > through it. It is only a configuration interface.
> > So you would tell the, yet-to-be-written userspace tool wconfig (or something
> > like that) "I need a STA in INFRA mode and want to drive it on the
> > wlan0 card". So wconfig goes and write()s some data to /dev/wlan0
> > telling the 80211 code to setup a virtual net_device for the driver
> > associated to /dev/wlan0.
> > The virtual interface is then configured though /dev/wlan0 using write()
> > (no ugly ioctl anymore, you see...). Config data like TX rate,
> > current essid,.... basically everything + xyz which is done by WE today,
> > is written to /dev/wlan0.
> > This config data is entirely cached in the 80211 code for the /dev/wlan0
> > instance. This is important, to have the data persistent throughout
> > suspend/resume cycles, if up/down cycles.
> > After configuring, a virtual net_device (let's call it wlan0) exists,
> > which can be brought up by ifconfig and data can be transferred though
> > it as usual.
> 
> what is wrong with using netlink and/or sysfs for it? I don't see the
> advantage of defining another /dev something interface.

Nothing is wrong with that.
"brainstorming" was the most dominant word in the whole text. ;)
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).
The _real_ main point I wanted to make was to _not_ use a net_device for
the master device. What else should be used for master device, let it
be a device node or a netlink socket, is rather unimportant at
this stage.

-- 
Greetings Michael.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Michael Buesch <mbuesch-KuiJ5kEpwI6ELgA04lAiVw@public.gmane.org>
To: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Cc: jgarzik-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org,
	bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [Fwd: State of the Union: Wireless]
Date: Fri, 6 Jan 2006 12:45:55 +0100	[thread overview]
Message-ID: <200601061245.55978.mbuesch@freenet.de> (raw)
In-Reply-To: <1136547494.7429.72.camel@localhost>

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

On Friday 06 January 2006 12:38, you wrote:
> Hi Michael,
> 
> > How would the virtual interfaces look like? That is quite easy to answer.
> > They are net_devices, as they transfer data.
> > They should probaly _not_ be on top of the ethernet, as 80211 does not
> > have very much in common with ethernet. Basically they share the same
> > MAC address format. Does someone have another thing, which he thinks
> > is shared?
> > How would the master interface look like? A somewhat unusual idea came
> > up. Using a device node in /dev. So every wireless card in the system
> > would have a node in /dev associated (/dev/wlan0 for example).
> > A node for the master device would be ok, because no data is transferred
> > through it. It is only a configuration interface.
> > So you would tell the, yet-to-be-written userspace tool wconfig (or something
> > like that) "I need a STA in INFRA mode and want to drive it on the
> > wlan0 card". So wconfig goes and write()s some data to /dev/wlan0
> > telling the 80211 code to setup a virtual net_device for the driver
> > associated to /dev/wlan0.
> > The virtual interface is then configured though /dev/wlan0 using write()
> > (no ugly ioctl anymore, you see...). Config data like TX rate,
> > current essid,.... basically everything + xyz which is done by WE today,
> > is written to /dev/wlan0.
> > This config data is entirely cached in the 80211 code for the /dev/wlan0
> > instance. This is important, to have the data persistent throughout
> > suspend/resume cycles, if up/down cycles.
> > After configuring, a virtual net_device (let's call it wlan0) exists,
> > which can be brought up by ifconfig and data can be transferred though
> > it as usual.
> 
> what is wrong with using netlink and/or sysfs for it? I don't see the
> advantage of defining another /dev something interface.

Nothing is wrong with that.
"brainstorming" was the most dominant word in the whole text. ;)
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).
The _real_ main point I wanted to make was to _not_ use a net_device for
the master device. What else should be used for master device, let it
be a device node or a netlink socket, is rather unimportant at
this stage.

-- 
Greetings Michael.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2006-01-06 11:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1136541243.4037.18.camel@localhost>
2006-01-06 11:00 ` [Bcm43xx-dev] [Fwd: State of the Union: Wireless] Michael Buesch
2006-01-06 11:38   ` Marcel Holtmann
2006-01-06 11:45     ` Michael Buesch [this message]
2006-01-06 11:45       ` Michael Buesch
2006-01-06 12:10       ` [Bcm43xx-dev] " Marcel Holtmann
2006-01-06 12:46         ` Patrick McHardy
2006-01-06 18:23           ` Stephen Hemminger
2006-01-06 22:16           ` David Lang
2006-01-06 22:18             ` David S. Miller
2006-01-09 18:24               ` Ingo Oeser
2006-01-06 22:22             ` Patrick McHardy
2006-01-12 14:20           ` Harald Welte
2006-01-06 16:12       ` Feyd
2006-01-06 16:25         ` Johannes Berg
2006-01-06 16:04   ` State of the Union: Wireless Mike Kershaw
2006-01-06 17:02   ` [Bcm43xx-dev] [Fwd: State of the Union: Wireless] Ben Greear
     [not found] <5rXDU-5s4-7@gated-at.bofh.it>
     [not found] ` <5rXDU-5s4-5@gated-at.bofh.it>
2006-01-06 22:57   ` Bodo Eggert
2006-01-06 22:57     ` Bodo Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200601061245.55978.mbuesch@freenet.de \
    --to=mbuesch@freenet.de \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.