Re: 2.6.20-rc6-mm3

[Thomas Gleixner]

On Tue, 2007-02-06 at 12:40 -0800, Daniel Walker wrote:
> > Yes, it is different. Why are you insisting, that something is a problem
> > just because it is different ?
> 
> In this case "different" goes into userspace .. So different could mean
> userspace regression, which is something that we don't want. I have no
> idea if any apps use /proc/interrupts , but it's possible since it's
> been around for a long time.

It _IS_ statistics info about the number of interrupts and has no fixed
meaning at all. It does not cause any user space regression, as the
interface is still the same. It produces different numbers, like the
clock_getres() syscall returns different values on highres and !highres
systems.

> The reason that I'm bringing it up at all is because people have ask me
> "Why isn't my timer ticking??"

So it's a problem of user perception and not of a user space regression.
Please stop confusing things.

> Your saying we can't remove it tho, if /proc/interrupts is not related
> to timers why does the entry exist at all ? Your saying the LOC entry is
> the new "timer" entry, but we still have the old "timer" entry ..

Ok. Each irqaction struct which is used to request/setup an interrupt
contains a name field. This is the one which shows up
in /proc/interrupts. The one which is used to setup irq0 has .name =
"timer". 

> Getting confusing ..

Sigh.

> It might be nicer to list all the registered clock event sources
> in /proc/interrupts, with more descriptive names .. 

No. No. No. clockevents has nothing to do with /proc/interrupts.

/proc/interrupts is the statistics interface for the IRQ subsystem.

> Why is it that HRT doesn't use the "timer" as a valid timer?

Because local apic timer is better.

	tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/