From: Darren.Reed@Sun.COM
To: Patrick Schaaf <bof@bof.de>
Cc: netfilter-devel@lists.netfilter.org,
Jan Engelhardt <jengelh@linux01.gwdg.de>,
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Subject: Re: Developing a user space library for filtering
Date: Tue, 22 May 2007 13:50:20 -0700 [thread overview]
Message-ID: <4653578C.3070407@Sun.COM> (raw)
In-Reply-To: <20070522064613.GA27619@oknodo.bof.de>
Patrick Schaaf wrote:
>...
>Anyway, regarding the original request, I don't think it is sensible to
>expect from netfilter developers to invent such a library, especially
>when the scope is desired to be abstracting from netfilter.
>
At this point in time, I was looking for people who might be interested
in helping design such an API. In the end, what I'm hoping for is to
have a common API delivered as part of OpenSolaris as well as both
FreeBSD and NetBSD. Given that it's still being drafted, I'm opening
the door and asking if there is anyone from Linux who's interested in
participating. I should point out that I'm not interested in requesting
anyone here write code that isn't [L]GPL'd.
...
> Bringing back that
>analogy, it would be a task for the developers of a vastly successful
>high level firewall application running on all kinds of basic firewalls.
>
>
Why should they have to do that? That requires:
1) they understand the API of every firewall they support
2) to track the API changes of every firewall they support
3) recompile/redeliver their software every time that API changes
None of those 3 options are what I would call palatable.
Imagine if everytime a new glibc was delivered you needed to
recompile all of your programs, from ls all the way through to the
X server, or...
>Personally, I think that it would be bound to fail anyway, because
>different basic firewall structures are very different in what and
>how they operate. But that's just the fast opinion of somebody who
>has neither need nor vision for userlevel firewall applications
>and systems other than Linux/netfilter.
>
>
The point of this is to understand that the low level/basic
structures of firewall software are quite different but the
"end goal" is the same.
For example, all firewalls let you say "block traffic between
X & Y", it is just how that is done which is different. The
idea is to capture the high level goals (c.f. "block ..")
into an API that applications can use.
Darren
next prev parent reply other threads:[~2007-05-22 20:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-21 22:27 Developing a user space library for filtering Darren.Reed
2007-05-21 22:47 ` Carl-Daniel Hailfinger
2007-05-21 22:52 ` Darren.Reed
2007-05-22 6:27 ` Jan Engelhardt
2007-05-22 6:46 ` Patrick Schaaf
2007-05-22 20:50 ` Darren.Reed [this message]
2007-05-22 21:14 ` Phil Dibowitz
2007-05-22 22:58 ` Henrik Nordstrom
2007-05-22 23:55 ` Darren.Reed
2007-05-23 0:29 ` Philip Craig
2007-05-23 8:19 ` Henrik Nordstrom
2007-05-22 7:11 ` Allen Francom
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=4653578C.3070407@Sun.COM \
--to=darren.reed@sun.com \
--cc=bof@bof.de \
--cc=c-d.hailfinger.devel.2006@gmx.net \
--cc=jengelh@linux01.gwdg.de \
--cc=netfilter-devel@lists.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.