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-
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
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
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/
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
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:
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 -
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: &
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
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
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
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
"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
"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
14 matches
Mail list logo
