These scripts are also broken. If you want to stop core files try using
limit coresize 0. I could just about forgive CVS getting core wrong [so
much for platform independance] if it didnt do totally stupid things like
not spotting core as file v core as directory. It should either keep its nose
out of the business or be educated first.
> From: Todd Fries <tfries@umr.edu>
> Date: Tue, 18 Jul 1995 16:46:01 -0600 (CDT)
> Subject: proc dates?
>
> I was just thinking--would it be possible or
> practical to 'datestamp' the files in the proc tree
> not based on the last time the directory was read, but
> upon the last time the information in the 'file'
> changed?
The information it has is normally generated on the fly. I have thought about
putting a version pointer with each entry - in my case because I happen to
like the idea of select() on /proc/net/route.
> From: mucci@cs.utk.edu
>
> I see in 1.2.10 the auto irq detection isn't turned on. I take it
> this means that it wasn't particularly stable?
Its not normally useful. And the 2e8 address causes problems with partial
decoding and some video boards. I've been auto IRQing my other 4 ports
for a long time with no glitches.
> From: Karl Keyte <kkeyte@koft.rhein-main.de>
> Date: Tue, 18 Jul 1995 19:44:21 +0200 (MET DST)
> Subject: Number of sockets
>
> I've just upgraded to 1.3.11 and have noticed that I run out
> of sockets very easily. In fact, I just log in on two virtual
> consoles and try to start two ftp's to localhost and one hangs
> until the other finishes because of the available TCP sockets.
> Is this just 1.3.11 or have I been missing something?
Sounds like a problem. I can't duplicate it offhand but 1.3.11 does
do interesting things with memory it doesnt own.
> From: "Theodore Ts'o" <tytso@mit.edu>
> The advantage of such a system, by the way, is that it's much cheaper to
> mask just one particular interrupt, since all you need to do is set a
> bit in the interrupt mask variable in memory. In contrast, under Linux,
> in order to mask an interrupt, you have to directly reprogram the
Doesnt this ignore the cost of queueing the interrupt in software - the
context switches register saves and cache pollution. The top end pentiums
with APIC's rewrite the rules again.
> interrupt controller, which is expensive. (Even just cli()/sti() is
> expensive.) A further advantage of handling interrupt masking in
About 1 clock cycle plus whatever cost to make sure register cached variables
hit ram before you unmask. cli/sti just flips the CPU flag.
> software is that it may make things much easier in multiprocessor
> systems.
Multiprocessor PC systems at least have fast interrupt controllers with
priorities and masks on board, as well as a very clever 'focus' scheme where
repeated IRQ's chase the person handling the current one.
Alan