All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Pierre Chifflier <chifflier@edenwall.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	netfilter-devel@vger.kernel.org, eleblond@edenwall.com
Subject: Re: [PATCH 1/2] Add new input plugin UNIXSOCK
Date: Fri, 05 Mar 2010 12:15:14 +0100	[thread overview]
Message-ID: <4B90E7C2.6030208@trash.net> (raw)
In-Reply-To: <20100228180505.GD16135@piche.inl.fr>

Pierre Chifflier wrote:
> On Sun, Feb 28, 2010 at 05:28:38PM +0100, Pablo Neira Ayuso wrote:
>>>>> +struct ulogd_unixsock_option_t  {
>>>>> +	uint16_t option_id;
>>>>> +	uint16_t option_length;
>>>>> +	char     option_value[0];
>>>>> +} __attribute__((packed));
>>>>> +
>>>>> +#define ALIGN_SIZE 8
>>>> Minor question: why align this to 64 bits?
>>> I originally used an alignment to 32 bits, but Jan noticed it would
>>> break if using options/values on 64 bits (and a test confirmed that). I
>>> took 64 bits as the biggest allowed value for integers.
>> I would need to look into this in more detail, not sure where the
>> problem is. I think that you can use something like `struct nlattr' (see
>> include/linux/netlink.h) and then nla_put() to add attributes in the TLV
>> format (see lib/nlattr.c). Those are align-safe. I'm using something
>> similar for conntrackd for the synchronization messages (src/build.c and
>> src/parse.c).
>>
> 
> Yes, this is very similar though NLA_ALIGNTO is set to 4 which will
> cause problems with 64 bits integers.
> The other way to solve this would be to read integers byte per byte,
> like in [1], but I found this not very elegant (and is likely to be slow
> compared to aligned access).
> 
> Or do you have any preferred solution ? Maybe using nlattr + one special
> function for dealing with 64 bits variables ?

I'd suggest to add a function that reads the data in 4 byte
quantities.

  parent reply	other threads:[~2010-03-05 11:15 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-26 20:54 [ULOGD2] UNIXSOCK plugin (v5) Pierre Chifflier
2010-02-26 20:54 ` [PATCH 1/2] Add new input plugin UNIXSOCK Pierre Chifflier
2010-02-27 13:55   ` Pablo Neira Ayuso
2010-02-28 14:06     ` Pierre Chifflier
2010-02-28 16:28       ` Pablo Neira Ayuso
2010-02-28 17:29         ` Jan Engelhardt
2010-02-28 18:05         ` Pierre Chifflier
2010-03-01 19:33           ` Pablo Neira Ayuso
2010-03-01 22:16             ` [ULOGD2] UNIXSOCK plugin (v6) Pierre Chifflier
2010-03-01 22:16             ` [PATCH 1/2] Add new input plugin UNIXSOCK Pierre Chifflier
2010-03-01 22:16             ` [PATCH 2/2] Add helper script pcap2ulog Pierre Chifflier
2010-03-03 17:42             ` [PATCH 1/2] Add new input plugin UNIXSOCK Jan Engelhardt
2010-03-03 18:14               ` Jan Engelhardt
2010-03-05 10:25               ` libnetfilter_conntrack alignment issue [was Re: [PATCH 1/2] Add new input plugin UNIXSOCK] Pablo Neira Ayuso
2010-03-07 19:30                 ` Jan Engelhardt
2010-03-05 11:15           ` Patrick McHardy [this message]
2010-03-05 17:10             ` [PATCH 1/2] Add new input plugin UNIXSOCK Pablo Neira Ayuso
2010-03-08 11:13               ` Patrick McHardy
2010-02-26 20:54 ` [PATCH 2/2] Add helper script pcap2ulog Pierre Chifflier
2010-02-27 10:46 ` [ULOGD2] UNIXSOCK plugin (v5) Eric Leblond
  -- strict thread matches above, loose matches on Subject: below --
2010-10-20 11:44 [ULOGD2] UNIXSOCK plugin (v5b) Pierre Chifflier
2010-10-20 11:44 ` [PATCH 1/2] Add new input plugin UNIXSOCK Pierre Chifflier
2010-01-14 19:41 [ULOGD2] UNIXSOCK plugin (v4) Pierre Chifflier
2010-01-14 19:41 ` [PATCH 1/2] Add new input plugin UNIXSOCK Pierre Chifflier
2009-11-01 10:53 [ULOGD2] UNIXSOCK plugin (v3) Pierre Chifflier
2009-11-01 10:53 ` [PATCH 1/2] Add new input plugin UNIXSOCK Pierre Chifflier
2009-11-01 12:45   ` Jan Engelhardt
2009-11-01 13:07     ` Pierre Chifflier
2009-11-01 13:41       ` Jan Engelhardt
2009-11-01 17:01         ` Pierre Chifflier
2009-11-02  6:22         ` David Miller
2009-11-03 17:01           ` Jan Engelhardt
2009-11-06 20:09             ` Pierre Chifflier
2009-11-09 13:09               ` Patrick McHardy

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=4B90E7C2.6030208@trash.net \
    --to=kaber@trash.net \
    --cc=chifflier@edenwall.com \
    --cc=eleblond@edenwall.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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.