All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Eric Leblond <eric@inl.fr>
Cc: Netfilter Development Mailinglist
	<netfilter-devel@vger.kernel.org>,
	Pierre Chifflier <chifflier@inl.fr>
Subject: Re: ulogd2 commit
Date: Sat, 18 Apr 2009 14:05:56 +0200	[thread overview]
Message-ID: <49E9C224.6060606@netfilter.org> (raw)
In-Reply-To: <1240055885.10215.27.camel@ice-age>

Eric Leblond wrote:
> Hi,
> 
> Le samedi 18 avril 2009 à 13:43 +0200, Pablo Neira Ayuso a écrit :
>> Eric Leblond wrote:
>>> Hi,
>>>
>>> Le vendredi 17 avril 2009 à 12:52 +0200, Pablo Neira Ayuso a écrit :
> 
> ...
> 
>> 1) Looking at my ulogd2 installation, this exports a lot of header files
>> for external use:
>>
>> $ ls /usr/include/ulogd/
>> common.h    hash.h            jhash.h      linux_rbtree.h  timer.h
>> conffile.h  ipfix_protocol.h  linuxlist.h  slist.h         ulogd.h
>>
>> Sorry, but this is a bit nasty. If this patch aims to allow compiling
>> external ulogd2 module,  please make public only the basic functions
>> (register, unregister, ...) in one header public file called ulogd.h or
>> something like that. But not exporting all those jhash.h, linux_rbtree.h
>> and so on.
> 
> Your point is correct...
> 
>> 2) Related to the previous point, if we make public some API, we'll have
>> to get attached to them to ensure backward compatibility. If we support
>> external modules, we'll have to engage to not changing the exported API,
>> otherwise people may complain about breakages of their external modules.
>> All those files that you have exported means quite a lot APIs that we'll
>> have to get attached to.
> 
> 
> This is not what I was trying to do. The only goal was compilation
> outside of tree. Target was not to provide a complete and fixed plugin
> infrastructure. In this case, a clean and stable API is really needed. 

Yes, but that compilation needs those header files to compile because it
will use functions that are implemented in ulogd2, right? Otherwise, I
don't see the point of making them all public.

>> I have my concerns with regards to this patch from both the technical
>> approach and the new policy that it introduces.
> 
> I agree for a revert of this commit. I can push it if you want.

Please, go ahead. Thanks Eric.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2009-04-18 12:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-17 10:52 ulogd2 commit Pablo Neira Ayuso
2009-04-18 11:17 ` Eric Leblond
2009-04-18 11:43   ` Pablo Neira Ayuso
2009-04-18 11:58     ` Eric Leblond
2009-04-18 12:05       ` Pablo Neira Ayuso [this message]

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=49E9C224.6060606@netfilter.org \
    --to=pablo@netfilter.org \
    --cc=chifflier@inl.fr \
    --cc=eric@inl.fr \
    --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 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.