RadioTap Archive on lore.kernel.org
 help / color / Atom feed
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org
Subject: Re: [RFA] TLV fields for radiotap
Date: Tue, 20 Nov 2018 21:09:39 +0100
Message-ID: <81658b7a400e6189c55587c8276d5555b6fe37f0.camel@sipsolutions.net> (raw)
In-Reply-To: <1536063298.3940.12.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

On Tue, 2018-09-04 at 14:14 +0200, Johannes Berg wrote:
> On Mon, 2018-07-09 at 10:47 +0200, Johannes Berg wrote:
> > Since there were no comments, let's make this more formal. Any
> > objections now?
> 
> Does this look like a good idea/compromise?
> 
> It's hard to do an entirely new version, then at least in Linux we'd
> probably have to be able to switch versions on the fly for some time,
> which is awkward ... but OTOH this feels a bit hackish.
> 
> No comments at all? :)

*crickets*

I guess I'll propose this more formally, since nobody really seems to
have any thoughts on the matter and parsing radiotap is notoriously
difficult :-)

FWIW, especially with vendor fields, there's a problem today: these
always come more or less last, so you have to understand all bits before
them. This is also true for radiotap, but due to sequential allocation,
if you care about a certain field today, your software is guaranteed to
be able to read it in the future too. If your software cares about a
vendor radiotap field, that's not true since other new standard fields
may be inserted before it...

Speak up now if you do think it's a bad idea ;-)

johannes

  parent reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09  8:47 Johannes Berg
     [not found] ` <1531126034.3298.18.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-09-04 12:14   ` Johannes Berg
     [not found]     ` <1536063298.3940.12.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-11-20 20:09       ` Johannes Berg [this message]
     [not found]         ` <81658b7a400e6189c55587c8276d5555b6fe37f0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-12-18  2:05           ` David Young
     [not found]             ` <20181218020526.GH27633-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2018-12-18 13:45               ` Johannes Berg
     [not found]                 ` <2c771c875d88d51d1cd98023686f084a5b6486bc.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2019-04-09  8:38                   ` Johannes Berg
2019-04-09  8:51 Johannes Berg

Reply instructions:

You may reply publically 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=81658b7a400e6189c55587c8276d5555b6fe37f0.camel@sipsolutions.net \
    --to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
    --cc=radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.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

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git