Re: linux-kernel-digest V1 #123

Alan Cox (
Mon, 24 Jul 1995 17:19:59 +0100 (BST)

> From:
> Date: Tue, 18 Jul 1995 16:46:36 -0400 (EDT)
> Subject: Re: using "core" as directory name
> > Instead of renaming any directory named "core", please mail a bug
> > report to the CVS team at <> about this. I Cc'ed
> > them this message.
> No, the file name "core" has pretty specific meaning, and CVS is
> probably not wrong. It seems extremely unwise to name anything
> important "core", if only because people write scripts that find and
> remove such files.

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 <>
> 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:
> 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 <>
> 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" <>
> 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.