netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Simon Barber <simon@devicescape.com>
Cc: Jiri Benc <jbenc@suse.cz>, netdev <netdev@vger.kernel.org>,
	Jeff Garzik <jgarzik@pobox.com>,
	"John W. Linville" <linville@tuxdriver.com>,
	Michael Buesch <mbuesch@freenet.de>,
	Ivo van Doorn <ivdoorn@gmail.com>,
	Michael Wu <flamingice@sourmilk.net>,
	Jouni Malinen <jkm@devicescape.com>,
	Daniel Drake <dsd@gentoo.org>, Hong Liu <hong.liu@intel.com>,
	"Luis R. Rodriguez" <mcgrof@gmail.com>,
	James Ketrenos <jketreno@linux.intel.com>,
	David Kimdon <dwhedon@devicescape.com>,
	Udayan Singh <udayan.singh@gmail.com>
Subject: RE: wireless notes / pre d80211 merge
Date: Wed, 15 Nov 2006 11:03:10 +0100	[thread overview]
Message-ID: <1163584990.2705.32.camel@ux156> (raw)
In-Reply-To: <C86180A8C204554D8A3323D8F6B0A29F0192722C@dhost002-46.dex002.intermedia.net>


> I would go further - and perhaps move some of the meta-data that is in
> the skb->cb into a d80211 specific hardware header. This would allow
> sniffers to directly attach to the master device and both send and
> receive frames complete with the meta data. It would also reduce the
> amount of cb space we need. Virtual devices could be created in order to
> use sniffers that use a different hardware header format (with a small
> performance penalty when using those).

I'm not sure this is a good idea, it locks us in to some format because
user-space uses it and we'd need to serialise to that format to be
extensible.

On the other hand, we could fix some part of the structure to be
user-space visible, make it a real struct that just lives before the
802.11 header and don't serialise like it would be necessary with
something that is extensible. On RX, we could do the same.

For TX, this would allow applications to control whatever we put into
that struct (I would not, for example, allow tx status notifications to
ever go over a netdev as we do now), while for RX it would allow apps to
see almost everything.

It might complicate code a bit because different things would come from
different places (some things from a special header and some from
skb->cb), but I don't think it would be bad.

Other than this, I agree with you.

johannes

  parent reply	other threads:[~2006-11-15 10:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-14 22:19 wireless notes / pre d80211 merge Johannes Berg
2006-11-15  0:11 ` Jiri Benc
2006-11-15  2:10   ` Simon Barber
2006-11-15  9:43     ` Jiri Benc
2006-11-15 10:13       ` Johannes Berg
2006-11-15 18:47       ` Jeff Garzik
2006-11-15 10:03     ` Johannes Berg [this message]
2006-11-15 18:46     ` Jeff Garzik
2006-11-15  9:16   ` Johannes Berg
2006-11-15 10:05     ` Jiri Benc
2006-11-15 10:16       ` Johannes Berg

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=1163584990.2705.32.camel@ux156 \
    --to=johannes@sipsolutions.net \
    --cc=dsd@gentoo.org \
    --cc=dwhedon@devicescape.com \
    --cc=flamingice@sourmilk.net \
    --cc=hong.liu@intel.com \
    --cc=ivdoorn@gmail.com \
    --cc=jbenc@suse.cz \
    --cc=jgarzik@pobox.com \
    --cc=jketreno@linux.intel.com \
    --cc=jkm@devicescape.com \
    --cc=linville@tuxdriver.com \
    --cc=mbuesch@freenet.de \
    --cc=mcgrof@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=simon@devicescape.com \
    --cc=udayan.singh@gmail.com \
    /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).