linux-kernel - Re: [PATCH] Intel IXP4xx network drivers v.3

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]

Message-ID: <m3ps5b5k07.fsf@maximus.localdomain>
Date:	Tue, 08 May 2007 18:59:36 +0200
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Lennert Buytenhek <buytenh@...tstofly.org>
Cc:	Michael-Luke Jones <mlj28@....ac.uk>,
	Jeff Garzik <jeff@...zik.org>, netdev@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>,
	Russell King <rmk@....linux.org.uk>,
	ARM Linux Mailing List 
	<linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: [PATCH] Intel IXP4xx network drivers v.3 - QMGR

Lennert Buytenhek <buytenh@...tstofly.org> writes:

> See for example arch/arm/mach-ep93xx/core.c, handling of the A/B/F
> port GPIO interrupts.
>
> In a nutshell, it goes like this.

Thanks, I will investigate.

>> There may be up to 6 Ethernet ports (not sure about hardware
>> status, not yet supported even by Intel) - 7 queues * 128 entries
>> each = ~ 3.5 KB. Add 2 long queues (RX) for HSS and something
>> for TX, and then crypto, and maybe other things.
>
> You're unlikely to be using all of those at the same time, though.

That's the point.

> And what do you do if the user does compile all of these features into
> his kernel and then tries to use them all at the same time?  Return
> -ENOMEM?

If he is able to do so, yes - there is nothing we can do. But
I suspect a single machine would not have all possible hardware.
The problem is, we don't know what would it have, so it must be
dynamic.

> Shouldn't we make sure that at least the features that are compiled in
> can be used at the same time?

We can't - hardware capabilities limit that. A general purpose
distribution would probably want to compile in everything (perhaps
as modules).

>  If you want that guarantee, then you
> might as well determine the SRAM map at compile time.

That would be most limiting with IMHO no visible advantage.
-- 
Krzysztof Halasa
-
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/