First of all, this is about the third time I've asked about this subject
on this mailing list, and I've never had anybody reply.
/taps microphone
Is this thing on?
I have been trying for several months to work out a way to parse the the
output of "cat /proc/net/xt_recent/<name of rule>", and return
meaningful numbers for the "last_seen" and "oldest_pkt" fields. As best
as I can determine, these are just a count of the number of jiffies
since boot. However, on a tickless kernel, there is really no well
defined number of jiffies per second as far as I can tell - it's going
to be a function of how often things need the system to wake up, and
will vary from moment to moment based upon the workload of the system.
If this is so, then this calls into question the utility of reporting
jiffies to the user - there's no way the user has to relate those values
to anything meaningful. It also calls into question the whole idea that
a recent rule can meaningfully specify a number of seconds for a packet
to be tested, if all that is stored is a number of jiffies.
So, the first question I have is: is there any meaningful way a
userspace tool can convert the values reported by /proc/net/xt_recent/*
into a wall clock time?
The second question is: if the answer to the first question is no, then
why report those values at all? The whole point of a procfile interface
is to report data to userspace, but if there is no meaningful way to use
that information, what good is it?
The third question is: wouldn't make more sense to capture the actual
wall-clock time of a packet, and report that to user space in a
meaningful way from the procfile interface? At least report time from
epoch in seconds - something that can be manipulated in a meaningful way?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
