RadioTap Archive on lore.kernel.org
 help / color / Atom feed
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: David Young <dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>,
	radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org
Subject: Re: [RFA] TLV fields for radiotap
Date: Tue, 18 Dec 2018 14:45:25 +0100
Message-ID: <2c771c875d88d51d1cd98023686f084a5b6486bc.camel@sipsolutions.net> (raw)
In-Reply-To: <20181218020526.GH27633-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>

Hi Dave,

> Sorry, I keep meaning to but forgetting to respond to this.

No worries, but thanks you took the time to.

> I had a thought about this tonight: maybe the solution is to define
> a new radiotap field, "hint," that contains a hint about the offset
> to a field.  The field begins with a 16-bit (?) field number, f, to
> be interpreted in the current namespace.  Following that is a 16-bit
> (?) absolute offset from the end of the hint field to field f.  If you
> introduce your vendor namespace when the last-assigned presence bit is
> bit p, and later you reuse the vendor namespace with newly-assigned
> presence bit p+k, then you can supply a hint for the vendor namespace
> field so that old readers can still benefit from presence bits 0..p and
> your vendor fields.
> 
> Anyway, I've only just thought-up the hint field, so I am not even sure
> that it's well-defined.

Hmm. Actually, yes, I think that would work. However, it's hard to guess
which fields the parser can do, so unless you have a really smart parser
you'd end up with

fields 0..n, hint, n+1, hint, n+2, hint, n+3, vendor_data

A smarter parser that understands 0..n+2 might be able to read

fields 0..n, hint, n+1, n+2, n+3, vendor_data

but it'd have to keep track of the hint, and if it doesn't care about
the contents of the hint ... it could still restart parsing at that
point.

Also, you'd have to reserve a high bit for the "hint" field in every
presence bitmap (like we do for the extension and namespace switching
bits), and to have multiple hint fields you'd have to extend your
presence bitmap all the time too.

Actually, you say "in the current namespace", so you'd have to switch
namespaces for the hint field to vendor, and then back to normal. If you
imagine doing this in the near future when we've run out of bits in the
first presence DWORD, then to have a hint field followed by e.g.
radiotap field 32 (next presence dword bit 0), you'd need

<presence dword: (fields 0..n) | extension | switch to vendor>
<presence dword: 0 | hint | extension | switch to radiotap>
<presence dword: 0 | extension>
<presence dword: field 32 i.e. BIT(0) | extension | switch to vendor>
<presence dword: vendor field>

There, the third presence dword is just a filler to reach the field32
again after the extension. This is also something we didn't really
consider when we designed the extension/namespace switching.

Personally, I feel this is too complex, and only really addresses the
one case I mentioned with vendor fields. I could, btw, also address it
today without the hint field by ordering the presence bitmaps
accordingly, i.e. putting the new unknown fields after the vendor
extension, by just extending the presence bitmap further and further.
But again, then I actually need to know which parts the tools can parse,
etc.

With TLVs, you could also imagine a tool that really only cares about a
single radiotap field, and is able to parse it out easily without
knowing about all the other fields.

I'll need to think about it more, but I tend to think the complexity of
the parser and generator are a bit too much. It's already hard enough
(too hard really) to parse radiotap, this only makes it even harder.

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
     [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 [this message]
     [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=2c771c875d88d51d1cd98023686f084a5b6486bc.camel@sipsolutions.net \
    --to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
    --cc=dyoung-e+AXbWqSrlAAvxtiuMwx3w@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