lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 24 Apr 2008 09:58:52 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	Jeff Garzik <jeff@...zik.org>,
	Rene Herman <rene.herman@...access.nl>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, rmk@....linux.org.uk,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [git patch] free_irq() fixes



On Thu, 24 Apr 2008, Eric W. Biederman wrote:
> 
> Right now the irq number is very much an array index and that
> property is limiting.

That's simply not true. 

You are looking at some implementation detail, but other architectures 
have used other notions.

The number is just that: a number. Nothing else. If you think it's an 
array index, you are looking at it in all the wrong ways.

So you're now complaining about somethign totally different than the type, 
you're talking about simple implementation issues.

And the reason it's generally implemented as a vector is very simple: it's 
basic to the whole notion that the hardware gives us some cookie (which 
itself is _often_ a small number, but sometimes is something that we can 
program), and we want to look up that cookie into our internal irq 
handling data structures.

So even when we can program the hw cookie arbitrarily (eg MSI), we 
actually tend to *want* to program it with something we can use as an 
array index, simply because that's often the best way to then map the 
hardware cookie into the internal "struct irq_desc" things.

So your argument MAKES ABSOLUTELY NO SENSE!

The reason we use something that _looks_ like an array index is that we 
ourself (and hardware) MADE IT SO.

It has absolutely nothing to do with the type of "irq". Even if "irq" was 
a pointer to a struct, we'd *still* want to have that array-index-like 
thing, and the only thing you could do would be to then use an extra level 
of indirection to turn it into something else!

So "irq" looks like an array index because we _avoid_ the indirection 
(except for the lookup of "irq_desc", which we absolutely do NOT want to 
expose to drivers!)

Your argument is utter crap, in other words. It makes no sense.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ