[PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

[PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

[Andy Fleming]

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@freescale.com>
---
This makes more sense to me, but I could be missing something?

 drivers/net/phy/Kconfig |    2 +-
 net/dsa/Kconfig         |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index d55932a..73027a0 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig PHYLIB
 	tristate "PHY Device support and infrastructure"
-	depends on !S390
+	depends on GENERIC_HARDIRQS
 	depends on NET_ETHERNET
 	help
 	  Ethernet controllers are usually attached to PHY
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 49211b3..ea9c5aa 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -1,7 +1,7 @@
 menuconfig NET_DSA
 	bool "Distributed Switch Architecture support"
 	default n
-	depends on EXPERIMENTAL && !S390
+	depends on EXPERIMENTAL && GENERIC_HARDIRQS
 	select PHYLIB
 	---help---
 	  This allows you to use hardware switch chips that use
-- 
1.5.4.GIT

Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

[David Miller]

From: Andy Fleming <afleming@freescale.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@freescale.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.

Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

[Andy Fleming]

On Tue, Oct 14, 2008 at 5:44 PM, David Miller <davem@davemloft.net> wrote:
> From: Andy Fleming <afleming@freescale.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@freescale.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

Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

[David Miller]

From: "Andy Fleming" <afleming@gmail.com>
Date: Tue, 14 Oct 2008 18:21:44 -0500

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

I think this whole situation with s390 is rediculious.

If s390 is weird and lacks these fundamental things, that's fine.
What isn't fine is how we're handling this.

No code should care or even be aware of this.

S390 should simply provide a set of dummy DMA and interrupt interface
stubs that always fail and return an error value.

Then we can get rid of this S390 Kconfig stuff which has been spewed
all over the place.

Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

[Chris Snook]

David Miller wrote:
> From: "Andy Fleming" <afleming@gmail.com>
> Date: Tue, 14 Oct 2008 18:21:44 -0500
> 
>> 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.
> 
> I think this whole situation with s390 is rediculious.
> 
> If s390 is weird and lacks these fundamental things, that's fine.
> What isn't fine is how we're handling this.
> 
> No code should care or even be aware of this.
> 
> S390 should simply provide a set of dummy DMA and interrupt interface
> stubs that always fail and return an error value.
> 
> Then we can get rid of this S390 Kconfig stuff which has been spewed
> all over the place.

"depends on PCI" has always worked for me.  Any reason we can't use that 
here?

-- Chris

Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

[David Miller]

From: Chris Snook <csnook@redhat.com>
Date: Tue, 14 Oct 2008 19:43:05 -0400

> David Miller wrote:
> > From: "Andy Fleming" <afleming@gmail.com>
> > Date: Tue, 14 Oct 2008 18:21:44 -0500
> > 
> >> 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.
> > I think this whole situation with s390 is rediculious.
> > If s390 is weird and lacks these fundamental things, that's fine.
> > What isn't fine is how we're handling this.
> > No code should care or even be aware of this.
> > S390 should simply provide a set of dummy DMA and interrupt interface
> > stubs that always fail and return an error value.
> > Then we can get rid of this S390 Kconfig stuff which has been spewed
> > all over the place.
> 
> "depends on PCI" has always worked for me.  Any reason we can't use that here?

That's every worse.

What in the world does PCI have to do with the attribute we are
trying to depend upon here?

No, it's just stupid.  Add nop do-nothing stub functions for the
APIs an architecture doesn't support, then we need none of this.

Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

[Chris Snook]

David Miller wrote:
> From: Chris Snook <csnook@redhat.com>
> Date: Tue, 14 Oct 2008 19:43:05 -0400
> 
>> David Miller wrote:
>>> From: "Andy Fleming" <afleming@gmail.com>
>>> Date: Tue, 14 Oct 2008 18:21:44 -0500
>>>
>>>> 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.
>>> I think this whole situation with s390 is rediculious.
>>> If s390 is weird and lacks these fundamental things, that's fine.
>>> What isn't fine is how we're handling this.
>>> No code should care or even be aware of this.
>>> S390 should simply provide a set of dummy DMA and interrupt interface
>>> stubs that always fail and return an error value.
>>> Then we can get rid of this S390 Kconfig stuff which has been spewed
>>> all over the place.
>> "depends on PCI" has always worked for me.  Any reason we can't use that here?
> 
> That's every worse.
> 
> What in the world does PCI have to do with the attribute we are
> trying to depend upon here?
> 
> No, it's just stupid.  Add nop do-nothing stub functions for the
> APIs an architecture doesn't support, then we need none of this.

But then it will be much more of a pain to exclude the vast swath of 
irrelevant code in the kernel tree from your builds on these exotic 
architectures.  Have you ever built a kernel on s390?  It's not exactly 
the architecture's strong suit, and cross-compilers have their own 
problems.  I don't care what it is, but we should have *some* mechanism 
for automatically excluding every PCI device driver in existence from 
our builds of s390 and any other similarly unusual architecture.

-- Chris

Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

[David Miller]

From: Chris Snook <csnook@redhat.com>
Date: Tue, 14 Oct 2008 20:07:55 -0400

> But then it will be much more of a pain to exclude the vast swath of
> irrelevant code in the kernel tree from your builds on these exotic
> architectures.  Have you ever built a kernel on s390?

That's totally irrelevant.

Does S390 have ethernet or ethernet-like devices?  If so, the someday
it might in fact might want to use something like phylib instead of
adding yet another implementation of programming a particular PHY
chip.

So in fact, something like phylib should be possible to enable even on
s390.

And this current situation means s390 builds get less coverage, making
allmodconfig test builds (which the s390 folks are obviously doing
since they hit this originally reported build failure) less
useful than they could be.

I would even be happy to make it such that SBUS drivers can be
enabled for test building on x86, and in fact right now in
Linus's tree that's very close to doable.

Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency

[Chris Snook]

David Miller wrote:
> From: Chris Snook <csnook@redhat.com>
> Date: Tue, 14 Oct 2008 20:07:55 -0400
> 
>> But then it will be much more of a pain to exclude the vast swath of
>> irrelevant code in the kernel tree from your builds on these exotic
>> architectures.  Have you ever built a kernel on s390?
> 
> That's totally irrelevant.
> 
> Does S390 have ethernet or ethernet-like devices?  If so, the someday
> it might in fact might want to use something like phylib instead of
> adding yet another implementation of programming a particular PHY
> chip.

Last I checked, s390 doesn't have any hardware that can't be shared 
between at least 64 guests.  The most Linux will ever control on that 
hardware is a software channel, be it a channel to a disk controller, 
network controller, or application-specific offload engine.  They don't 
really have NICs, more like a built-in router which can optionally fake 
layer 2 for the benefit of guests.

> So in fact, something like phylib should be possible to enable even on
> s390.
> 
> And this current situation means s390 builds get less coverage, making
> allmodconfig test builds (which the s390 folks are obviously doing
> since they hit this originally reported build failure) less
> useful than they could be.

Currently, allmodconfig on s390 is cheap, because there's a miniscule 
amount of device driver code that can be enabled in Kconfig.  If you 
enabled all those other drivers to build on s390, it would take *days* 
to complete an allmodconfig build natively or in an emulator.  Forcing 
people to use cross-compilers to get things done at a reasonable pace 
would mean treating s390 differently from other architectures in 
multi-platform build systems, and would probably have the effect that 
nobody outside of IBM would do any significant build testing on that 
architecture.

> I would even be happy to make it such that SBUS drivers can be
> enabled for test building on x86, and in fact right now in
> Linus's tree that's very close to doable.

I have no objection to that.  I have MIPS to burn on my x86 boxes.  s390 
MIPS cost a few orders of magnitude more.

-- Chris