From: David Young <dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
To: radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org
Subject: Re: [RFA] TLV fields for radiotap
Date: Mon, 17 Dec 2018 20:05:26 -0600 [thread overview]
Message-ID: <20181218020526.GH27633@pobox.com> (raw)
In-Reply-To: <81658b7a400e6189c55587c8276d5555b6fe37f0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On Tue, Nov 20, 2018 at 09:09:39PM +0100, Johannes Berg wrote:
> 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*
Sorry, I keep meaning to but forgetting to respond to this.
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.
Dave
--
David Young
dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org Urbana, IL (217) 721-9981
next prev parent reply other threads:[~2018-12-18 2:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 8:47 [RFA] TLV fields for radiotap 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 [this message]
[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 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=20181218020526.GH27633@pobox.com \
--to=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
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).