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: <2acbd3e40810141621p31ba3ccdic909fc4634b5ef26@mail.gmail.com>
Date:	Tue, 14 Oct 2008 18:21:44 -0500
From:	"Andy Fleming" <afleming@...il.com>
To:	"David Miller" <davem@...emloft.net>
Cc:	afleming@...escale.com, netdev@...r.kernel.org
Subject: Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

On Tue, Oct 14, 2008 at 5:44 PM, David Miller <davem@...emloft.net> wrote:
> From: Andy Fleming <afleming@...escale.com>
> Date: Tue, 14 Oct 2008 17:28:13 -0500
>
>> PHY Lib and DSA expect request_irq and other such functions to exist.
>> S390 doesn't support those functions, however we should mark the actual
>> dependency, which is generic hardirq support, rather than explicitly
>> depend on !S390.
>>
>> Signed-off-by: Andy Fleming <afleming@...escale.com>
>> ---
>> This makes more sense to me, but I could be missing something?
>
> GENERIC_HARDIRQS is not the correct dependency.
>
> Not all architectures use the generic IRQ layer, yet have
> support for interrupts (request_irq(), free_irq(), etc.)
>
> Two such platforms are 32-bit sparc and m68k.


Argh.  From what I could see, we have request_irq, free_irq,
disable_irq, enable_irq, and disable_irq_nosync.  For the PHYLIB, it
shouldn't be difficult to modify things so that it doesn't compile in
interrupt support if the system doesn't support them.  Shouldn't, that
is, if there's some config option that tells me whether those
functions exist.

Would it be acceptable to create a config option which *did* convey
this meaning?  Off the top of my head I can imagine either having
s390's Kconfig declare NO_HARDIRQ_SUPPORT.  Alternatively, it would be
less trivial, but fairly easy to create a config option,
HARDIRQ_SUPPORT, which is either selected by arches which define their
own request_irq, etc functions, or automatically selected when
GENERIC_HARDIRQS is selected.

Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ