All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven@narfation.org>
To: Antonio Quartulli <ordex@autistici.org>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] Combination of flags in tt_query packets
Date: Mon, 13 Jun 2011 16:29:16 +0200	[thread overview]
Message-ID: <201106131629.19141.sven@narfation.org> (raw)
In-Reply-To: <20110613132507.GA18690@ritirata.org>

[-- Attachment #1: Type: Text/Plain, Size: 2511 bytes --]

Antonio Quartulli wrote:
> > just looked a little bit closer at your tt_query implementation and was
> > reminded that we had a small discussion in IRC some weeks ago.
> > 
> > <ecsv> can those flags be mixed?
> > <ordex> mixed? in which way?
> > <ecsv> request | table -> still a valid package
> > <ecsv> sry, packet
> > <ordex> yes it is, because it means "I'm requesting a full table"
> > <ordex> all the combinations are valid
> > 
> > This sounds wrong when I look at the tt_query packet. There we have a
> > tt_data field which can used used exclusive by either TT_REQUEST (x)or
> > TT_RESPONSE. Therefore, it is not possible to use both flags at the same
> > time. Can you please explain how this is handled or otherwise change it
> > so that only one bit in flags is used to decide if it is an response or
> > a request.
> 
> At the beginning we had one bit only with this meaning:
> 
> 0 => TT_REQUEST
> 1 => TT_RESPONSE

Could be correct - never followed the discussion in detail. I asked Marek and 
he said something about roaming.

> But then we had a disussion about:
> 1) what will we do if we want to add more packet types in the future?

Depends on the type. For example full-table creates different packet types 
together with the TT_REQUEST and TT_RESPONSE. But using TT_REQUEST and 
TT_RESPONSE together doesn't work at all. So forget about the flag and think 
more about a currently undefined amount of bits which encode the type of 
packet. Encoding the request and reply in two different bits and call them 
flags doesn't really make sense. 

> 2) is it correct or not to use 0x0 as flag?

A not existing bit position is not really a "flag". The bit at position zero 
(lsb) could be used as flag to decide if it is a request or a response - but 
using nothing to store something is... <please insert your favourite swear 
word here>.

> Regarding 1) I thought that using a "two bits flag" could help in reserving
> two configurations more for the future (0x0 and 0x3).

Then you say that you don't use flags but 2 bits to store 2 values. Please 
don't use it in your code as flags, but use something like (x & TT_TYPE_MASK) 
to extract the corresponding bits and compare the resulting values against 
representation of TT_RESPONSE and TT_RESPONSE (TT_TYPE_MASK would be 0x3, 
TT_RESPONSE 0 and TT_REQUEST 3). Also remove the TT_RESPONSE and TT_REQUEST 
from the enum tt_query_flags and use another enum for them.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2011-06-13 14:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-12  9:52 [B.A.T.M.A.N.] Combination of flags in tt_query packets Sven Eckelmann
2011-06-13 13:25 ` Antonio Quartulli
2011-06-13 14:29   ` Sven Eckelmann [this message]
2011-06-13 14:30     ` Sven Eckelmann
2011-06-13 17:02     ` Antonio Quartulli

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=201106131629.19141.sven@narfation.org \
    --to=sven@narfation.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=ordex@autistici.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.