netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: Pierre Chifflier <chifflier@edenwall.com>,
	netfilter-devel@vger.kernel.org, eleblond@edenwall.com
Subject: Re: [PATCH 1/2] Add new input plugin UNIXSOCK
Date: Fri, 05 Mar 2010 18:10:28 +0100	[thread overview]
Message-ID: <4B913B04.6020701@netfilter.org> (raw)
In-Reply-To: <4B90E7C2.6030208@trash.net>

Patrick McHardy wrote:
> 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.

Would memcpy() be enough? If so, we can go back to the 4 bytes alignment.

  reply	other threads:[~2010-03-05 17:10 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           ` [PATCH 1/2] Add new input plugin UNIXSOCK Patrick McHardy
2010-03-05 17:10             ` Pablo Neira Ayuso [this message]
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=4B913B04.6020701@netfilter.org \
    --to=pablo@netfilter.org \
    --cc=chifflier@edenwall.com \
    --cc=eleblond@edenwall.com \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@vger.kernel.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).