then simply subtract a previous value from the current
value to get the difference. This works reliably across counter
wrap-arounds. There is absolutely *no need for reset* !
--
Manfred Bartz
---
ipchainsLogAnalyzer, NetCalc, whois at: &
Russell King <[EMAIL PROTECTED]> writes:
> On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote:
> > There is another issue with logging in general:
> >
> > *COUNTERS MUST NOT BE RESETABLE!!!*
>
> Umm, no. Counters can be resetable -
Leif Sawyer <[EMAIL PROTECTED]> writes:
> Manfred Bartz responded to
> > Russell King <[EMAIL PROTECTED]> who writes:
> >
> > > On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote:
> > > > There is another issue with logging in general:
Harald Welte <[EMAIL PROTECTED]> writes:
> On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote:
> > Resetable counters guarantee that no two programs can co-exists if
> > they happen to reset the same counters.
>
> That sounds like crap (sorry).
Care to
h more cruft.
Nonsense. Removing counter reset capabilities reduces kernel cruft.
--
Manfred Bartz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
n fix
> the application.
You are confused. What would you say if a close() by another,
unrelated application closed all open descriptors for that file,
including the one you just opened? Just fix your applications?
--
Manfred Bartz
-
To unsubscribe from this list: send the line "un
say if a close() by another,
>
> No he isnt confused, you are trying to dictate policy.
What then *is* the policy?
AFAIK, no counters in the Linux kernel have resets, except in netfilter.
--
Manfred Bartz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
tfm/>
<http://www.caida.org/>
Relevant RFCs include: 2720 ... 2724
Thanks
--
Manfred Bartz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-
I have 3 NICs (2*DEC, 1*3c509) in my gateway (P75, 40M RAM).
tulip.o in 2.4.1 insists on selecting 10baseT, no command
line option can convince it otherwise. tulip.o in 2.2.16 auto
detected media and worked fine.
de4x5.o in 2.4.1 needs to be told the media, then works fine.
de4x5.o in 2.2.16 au
Jeff Garzik <[EMAIL PROTECTED]> writes:
> On 20 Feb 2001, Manfred Bartz wrote:
> > I have 3 NICs (2*DEC, 1*3c509) in my gateway (P75, 40M RAM).
> >
> > tulip.o in 2.4.1 insists on selecting 10baseT, no command
> > line option can convince it otherwise. tulip.o
"Christopher Friesen" <[EMAIL PROTECTED]> writes:
> Has anyone ever considered including a microsecond-precision
> monotonically-increasing counter in the kernel? This would allow for
> easy timing of alarms and such by using absolute values of when the
> alarm should expire rather than a list o
"Christopher Friesen" <[EMAIL PROTECTED]> wrote:
> Manfred Bartz wrote:
>
> > Why a new system call?
> Well, you'd be accessing a different kernel variable--"ytime" instead of
> "xtime". This new variable wouldn't be adjusted whe
Jordan <[EMAIL PROTECTED]> writes:
> 1st, the Sony Vaio Z505HS appears to be an example of a machine which
> will not boot a bzImage correctly, compaining about the compression
> format.
Maybe you need to upgrade to a newer version of lilo?
> 2nd, trying to build kernel 2.4.0, I stripped out or
Josh Myer <[EMAIL PROTECTED]> writes:
> I know this _really_ isn't the forum for this, but a friend of mine has
> noticed major, persistent clock drift over time. After several weeks, the
> clock is several minutes slow (always slow). Any thoughts on the
> cause? (Google didn't show up anything w
14 matches
Mail list logo
