"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 when the system
time/date was, it would sta
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] 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 of
://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-info.html
Please read the FA
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
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
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 in 2.2.16 auto
detected media and worked
the difference. This works reliably across counter
wrap-arounds. There is absolutely *no need for reset* !
--
Manfred Bartz
---
ipchainsLogAnalyzer, NetCalc, whois at: http://logi.cc/linux/
NEW: http://logi.cc/linux
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 - you just specify that accounting
programs
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:
*COUNTERS MUST NOT BE RESETABLE
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 explain how two independent apps can
applications so they cooperate nicely.
They're still all met, right?
No. Because they require well behaved, cooperative user programs.
And we haven't had to fill the kernel with more cruft.
Nonsense. Removing counter reset capabilities reduces kernel cruft.
--
Manfred Bartz
() 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 "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
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
the body of a message to [EMAIL PROTECTED]
More majordomo inf
"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 when the sys
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
<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-info.html
"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
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
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
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
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
ft.
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/
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 "unsubscribe linux-kernel" i
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
28 matches
Mail list logo
