From: Patrick McHardy <kaber@trash.net>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: Netfilter Mailing List <netfilter@lists.netfilter.org>,
Netfilter Development Mailinglist
<netfilter-devel@lists.netfilter.org>
Subject: Re: Time module included in the default Fedora
Date: Wed, 11 Apr 2007 19:44:30 +0200 [thread overview]
Message-ID: <461D1E7E.1060705@trash.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0704111932500.20436@yvahk01.tjqt.qr>
Jan Engelhardt wrote:
> On Apr 11 2007 18:33, Patrick McHardy wrote:
>
>>The question whether to merge the time module came up repeatedely
>>at netfilter workshops, but it was always decided against it so far,
>>mainly because it apparently can't deal with timezones and daylight
>>saving time.
>
>
> Why, let iptables, or more precisely, ipt_time.c, handle timezones,
> and pass an UTC value to the kernel -- that's what it is best at
> dealing with.
Than it wouldn't be able to deal with DST I guess. As I said, the
kernel already has knowledge about the timezone, so it should be
possible to do this properly quite easily, but I have no interest
in doing this myself.
>>IIRC Harald had strong feelings about it, I personally
>>don't care much about this shortcoming as long as its documented.
>>I'm not even sure its correct since the kernel has sys_tz. So if
>>anyone finds out and submits a patch, I'll consider it.
>>
>>
>>>Though that leaves me puzzled why connlimit has not gone in yet
>>>(it all simplifies maintenance so much IMO). BTW, how about it?
>>
>>As I stated multiple times, the reason why its not included is that
>>its horribly slow. But since I don't see any better way to do this
>>and I know quite a few people are using this, I would consider this
>>as well if someone sends me a patch, which has not happened so far.
>
>
> So it's just that I need to pull the pomng code and make a diff out
> of it, is that all? (Plus any compilation and perhaps runtime fixes,
> of course.)
From a quick look I'd say:
- move to x_tables
- remove ip_conntrack stuff
- clean up
- fix up for recent API changes and improvements
- fix 32/64 bit issues
- use proper list macros
- use kzalloc
And explain to me why it needs knowledge about TCP states. That should
be enough to get a discussion started.
WARNING: multiple messages have this Message-ID (diff)
From: Patrick McHardy <kaber@trash.net>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: Netfilter Mailing List <netfilter@lists.netfilter.org>,
Netfilter Development Mailinglist
<netfilter-devel@lists.netfilter.org>
Subject: Re: Time module included in the default Fedora
Date: Wed, 11 Apr 2007 19:44:30 +0200 [thread overview]
Message-ID: <461D1E7E.1060705@trash.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0704111932500.20436@yvahk01.tjqt.qr>
Jan Engelhardt wrote:
> On Apr 11 2007 18:33, Patrick McHardy wrote:
>
>>The question whether to merge the time module came up repeatedely
>>at netfilter workshops, but it was always decided against it so far,
>>mainly because it apparently can't deal with timezones and daylight
>>saving time.
>
>
> Why, let iptables, or more precisely, ipt_time.c, handle timezones,
> and pass an UTC value to the kernel -- that's what it is best at
> dealing with.
Than it wouldn't be able to deal with DST I guess. As I said, the
kernel already has knowledge about the timezone, so it should be
possible to do this properly quite easily, but I have no interest
in doing this myself.
>>IIRC Harald had strong feelings about it, I personally
>>don't care much about this shortcoming as long as its documented.
>>I'm not even sure its correct since the kernel has sys_tz. So if
>>anyone finds out and submits a patch, I'll consider it.
>>
>>
>>>Though that leaves me puzzled why connlimit has not gone in yet
>>>(it all simplifies maintenance so much IMO). BTW, how about it?
>>
>>As I stated multiple times, the reason why its not included is that
>>its horribly slow. But since I don't see any better way to do this
>>and I know quite a few people are using this, I would consider this
>>as well if someone sends me a patch, which has not happened so far.
>
>
> So it's just that I need to pull the pomng code and make a diff out
> of it, is that all? (Plus any compilation and perhaps runtime fixes,
> of course.)
>From a quick look I'd say:
- move to x_tables
- remove ip_conntrack stuff
- clean up
- fix up for recent API changes and improvements
- fix 32/64 bit issues
- use proper list macros
- use kzalloc
And explain to me why it needs knowledge about TCP states. That should
be enough to get a discussion started.
next prev parent reply other threads:[~2007-04-11 17:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b317600c0704110750x30861e6ft6cd0a53d415cba74@mail.gmail.com>
2007-04-11 14:52 ` Time module included in the default Fedora Fred Trotter
2007-04-11 15:58 ` Jan Engelhardt
2007-04-11 16:33 ` Patrick McHardy
2007-04-11 17:15 ` Fred Trotter
2007-04-11 17:34 ` Jan Engelhardt
2007-04-11 17:44 ` Patrick McHardy [this message]
2007-04-11 17:44 ` Patrick McHardy
2007-04-11 17:55 ` Pascal Hambourg
2006-11-30 9:43 [RFC PATCH IPTABLES 0/12]: matches/targets unification Yasuyuki KOZAKAI
2006-11-30 13:35 ` Patrick McHardy
2006-12-03 4:36 ` Yasuyuki KOZAKAI
2006-12-06 10:25 ` Patrick McHardy
2006-12-06 12:33 ` Yasuyuki KOZAKAI
[not found] ` <200612061233.kB6CXNxL024591@toshiba.co.jp>
2006-12-06 17:40 ` Patrick McHardy
2006-12-06 20:49 ` Martin Josefsson
2006-12-07 3: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=461D1E7E.1060705@trash.net \
--to=kaber@trash.net \
--cc=jengelh@linux01.gwdg.de \
--cc=netfilter-devel@lists.netfilter.org \
--cc=netfilter@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.