netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Michael Buesch <mbuesch@freenet.de>
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, 06 Jan 2006 13:10:23 +0100	[thread overview]
Message-ID: <1136549423.7429.88.camel@localhost> (raw)
In-Reply-To: <200601061245.55978.mbuesch@freenet.de>

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. ;)

so I might got the wrong impression, because it seemed you put a lot of
thinking into the /dev/wlanX stuff without even considering netlink or
something else.

> 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.

> 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.

I am all for it, because I don't like dummy Ethernet devices that are
only used for configuration. I am still not happy that IrDA uses irda0
to get somekind of packet management etc. instead of implementing a real
suitable hardware abstraction.

Regards

Marcel

  reply	other threads:[~2006-01-06 12:10 UTC|newest]

Thread overview: 15+ 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
2006-01-06 12:10       ` Marcel Holtmann [this message]
2006-01-06 12:46         ` [Bcm43xx-dev] " 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 17:02   ` 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

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=1136549423.7429.88.camel@localhost \
    --to=marcel@holtmann.org \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbuesch@freenet.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).