From: Pavel Roskin <proski@gnu.org>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: netdev@vger.kernel.org, Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: Can we have GET_NETDEV_DEV?
Date: Tue, 25 Jul 2006 18:02:55 -0400 [thread overview]
Message-ID: <1153864975.2288.49.camel@dv> (raw)
In-Reply-To: <20060725142606.0a44d258@localhost.localdomain>
On Tue, 2006-07-25 at 14:26 -0700, Stephen Hemminger wrote:
> On Tue, 25 Jul 2006 17:08:11 -0400
> Pavel Roskin <proski@gnu.org> wrote:
> > Considering the drivers that are already in the kernel, you may prefer
> > to have a more high-level function that would clone the network device
> > by copying most of the net_device structure. I think netdev_get_pdev()
> > would be mostly used for such cloning if implemented.
> >
>
> What is the wireless tree using for this?
Suppose there is a wireless device that can be used on different buses,
e.g. PCI and PCMCIA. The driver consists of the common part that works
with the chip and the bus specific parts that allocate the resources.
The bus specific parts call SET_NETDEV_DEV to associate the network
device with the hardware device.
Now, suppose the user requests creating a WDS interface. WDS interfaces
use 4-address headers, which allows bridging. As it stands now, the way
to support a WDS interface is to make is a separate network device. I
wish it wouldn't be necessary, but we would need to change quite a few
code inside and outside the kernel to understand WDS addressing (I hope
to be wrong about that).
There is nothing hardware specific about WDS interfaces. They are just
extensions of the main interface with a fixed "receive address" and
4-address headers enabled. So it makes sense to create WDS interface in
the common (i.e. bus-agnostic) part of the driver.
In the (possibly misguided) attempt to make WDS network devices look
like real network interfaces, the "class_dev" field is copied from the
master network device, because it's something that can be done in the
bus-agnostic way:
SET_NETDEV_DEV(dev, mdev->class_dev.dev);
This is how it's done in HostAP (in the kernel) and MadWifi (outside the
kernel).
Sure, this value can be stored in the private part of the driver, so
it's a minor issue.
(Actually, the main (AP or STA) interface is also made a virtual network
device, so that the the master interface appears as the parent of the
main and the WDS devices and as the single point for monitoring of all
wireless traffic.)
--
Regards,
Pavel Roskin
next prev parent reply other threads:[~2006-07-25 22:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-25 4:52 Can we have GET_NETDEV_DEV? Pavel Roskin
2006-07-25 17:20 ` Stephen Hemminger
2006-07-25 21:08 ` Pavel Roskin
2006-07-25 21:26 ` Stephen Hemminger
2006-07-25 22:02 ` Pavel Roskin [this message]
2006-07-25 21:31 ` Greg KH
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=1153864975.2288.49.camel@dv \
--to=proski@gnu.org \
--cc=gregkh@suse.de \
--cc=netdev@vger.kernel.org \
--cc=shemminger@osdl.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).