[PATCH 00/33] dyn_array and nr_irqs support v4

[PATCH 00/33] dyn_array and nr_irqs support v4

[Yinghai Lu]

Please check dyn_array support for x86
v3: split changing to nr_irqs to small patches
    fix checkpatch error
    reorder the patch sequence to make dyn_array support go at first
        so could use that with arrays other than NR_IRQS
v4: add CONFIG_HAVE_SPARSE_IRQ with list to use condensed irq_desc array
    so could use 32 init, and init more if needed.

now: x86 32bit: have CONFIG_HAVE_DYN_ARRAY
     x86 64bit: have CONFIG_HAVE_DYN_ARRAY and CONFIG_HAVE_SPARSE_IRQ

left:
a. hook irq_2_iommu to irq_desc ?
b. expand /proc/interrupts to process > nr_irqs
c. expand to use irq > nr_irqs for msi

notes: may break some arch compling...

Thanks

Yinghai Lu

[PATCH 01/33] x86: add after_bootmem for 32bit

[Yinghai Lu]

to prepare to use dyn_array support etc.

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
 arch/x86/mm/init_32.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 4974e97..b5c1751 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -65,6 +65,7 @@ static unsigned long __meminitdata table_end;
 static unsigned long __meminitdata table_top;
 
 static int __initdata after_init_bootmem;
+int after_bootmem;
 
 static __init void *alloc_low_page(unsigned long *phys)
 {
@@ -924,6 +925,8 @@ void __init mem_init(void)
 
 	set_highmem_pages_init();
 
+	after_bootmem = 1;
+
 	codesize =  (unsigned long) &_etext - (unsigned long) &_text;
 	datasize =  (unsigned long) &_edata - (unsigned long) &_etext;
 	initsize =  (unsigned long) &__init_end - (unsigned long) &__init_begin;
-- 
1.5.4.5

[PATCH 02/33] x86: remove irq_vectors_limits

[Yinghai Lu]

no user

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
 include/asm-x86/mach-generic/irq_vectors_limits.h |   14 --------------
 include/asm-x86/summit/irq_vectors_limits.h       |   14 --------------
 2 files changed, 0 insertions(+), 28 deletions(-)
 delete mode 100644 include/asm-x86/mach-generic/irq_vectors_limits.h
 delete mode 100644 include/asm-x86/summit/irq_vectors_limits.h

diff --git a/include/asm-x86/mach-generic/irq_vectors_limits.h b/include/asm-x86/mach-generic/irq_vectors_limits.h
deleted file mode 100644
index f7870e1..0000000
--- a/include/asm-x86/mach-generic/irq_vectors_limits.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef ASM_X86__MACH_GENERIC__IRQ_VECTORS_LIMITS_H
-#define ASM_X86__MACH_GENERIC__IRQ_VECTORS_LIMITS_H
-
-/*
- * For Summit or generic (i.e. installer) kernels, we have lots of I/O APICs,
- * even with uni-proc kernels, so use a big array.
- *
- * This value should be the same in both the generic and summit subarches.
- * Change one, change 'em both.
- */
-#define NR_IRQS	224
-#define NR_IRQ_VECTORS	1024
-
-#endif /* ASM_X86__MACH_GENERIC__IRQ_VECTORS_LIMITS_H */
diff --git a/include/asm-x86/summit/irq_vectors_limits.h b/include/asm-x86/summit/irq_vectors_limits.h
deleted file mode 100644
index 890ce3f..0000000
--- a/include/asm-x86/summit/irq_vectors_limits.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef _ASM_IRQ_VECTORS_LIMITS_H
-#define _ASM_IRQ_VECTORS_LIMITS_H
-
-/*
- * For Summit or generic (i.e. installer) kernels, we have lots of I/O APICs,
- * even with uni-proc kernels, so use a big array.
- *
- * This value should be the same in both the generic and summit subarches.
- * Change one, change 'em both.
- */
-#define NR_IRQS	224
-#define NR_IRQ_VECTORS	1024
-
-#endif /* _ASM_IRQ_VECTORS_LIMITS_H */
-- 
1.5.4.5

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Eric W. Biederman]

Yinghai Lu <yhlu.kernel@gmail.com> writes:

> Please check dyn_array support for x86
> v3: split changing to nr_irqs to small patches
>     fix checkpatch error
>     reorder the patch sequence to make dyn_array support go at first
>         so could use that with arrays other than NR_IRQS
> v4: add CONFIG_HAVE_SPARSE_IRQ with list to use condensed irq_desc array
>     so could use 32 init, and init more if needed.
>
> now: x86 32bit: have CONFIG_HAVE_DYN_ARRAY
>      x86 64bit: have CONFIG_HAVE_DYN_ARRAY and CONFIG_HAVE_SPARSE_IRQ
>
> left:
> a. hook irq_2_iommu to irq_desc ?
> b. expand /proc/interrupts to process > nr_irqs
> c. expand to use irq > nr_irqs for msi
>
> notes: may break some arch compling...

It looks like you might possibly be iterating to something usable.
Breaking architectures is not acceptable however.

My suggestion for a non-breaking path:
- Kill NR_IRQS in then generic code.
  With Alan's serial patch and my kstat patch it looks like we have
  the worst of that.

- Introduce get_irq_desc and the functions or function modifications
  that pass a struct irq_desc * into the genirq code.

  Although I absolutely hate the name get_irq_desc as it implies we are
  reference counting something and need a corresponding put_irq_desc.
  Since the lifetime rules don't require that.  Please just call the
  function irq_desc().

- Update arch/x86 to do everything interesting with irq_desc pointers.

- Start dynamically allocating irq_desc and irq_cfg.

Eric

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Yinghai Lu]

On Wed, Aug 6, 2008 at 10:37 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Yinghai Lu <yhlu.kernel@gmail.com> writes:
>
>> Please check dyn_array support for x86
>> v3: split changing to nr_irqs to small patches
>>     fix checkpatch error
>>     reorder the patch sequence to make dyn_array support go at first
>>         so could use that with arrays other than NR_IRQS
>> v4: add CONFIG_HAVE_SPARSE_IRQ with list to use condensed irq_desc array
>>     so could use 32 init, and init more if needed.
>>
>> now: x86 32bit: have CONFIG_HAVE_DYN_ARRAY
>>      x86 64bit: have CONFIG_HAVE_DYN_ARRAY and CONFIG_HAVE_SPARSE_IRQ
>>
>> left:
>> a. hook irq_2_iommu to irq_desc ?
>> b. expand /proc/interrupts to process > nr_irqs
>> c. expand to use irq > nr_irqs for msi
>>
>> notes: may break some arch compling...
>
> It looks like you might possibly be iterating to something usable.
> Breaking architectures is not acceptable however.
>
> My suggestion for a non-breaking path:
> - Kill NR_IRQS in then generic code.
>  With Alan's serial patch and my kstat patch it looks like we have
>  the worst of that.

will use Alan's patch.at first.
already reused your patch about kstat. and move kstat_irqs to irq_desc.

>
> - Introduce get_irq_desc and the functions or function modifications
>  that pass a struct irq_desc * into the genirq code.
>
>  Although I absolutely hate the name get_irq_desc as it implies we are
>  reference counting something and need a corresponding put_irq_desc.
>  Since the lifetime rules don't require that.  Please just call the
>  function irq_desc().

will check that.

>
> - Update arch/x86 to do everything interesting with irq_desc pointers.
>
> - Start dynamically allocating irq_desc and irq_cfg.

already done in last 10 patches.

YH

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Yinghai Lu]

>>
>> - Introduce get_irq_desc and the functions or function modifications
>>  that pass a struct irq_desc * into the genirq code.
>>
>>  Although I absolutely hate the name get_irq_desc as it implies we are
>>  reference counting something and need a corresponding put_irq_desc.
>>  Since the lifetime rules don't require that.  Please just call the
>>  function irq_desc().
>
> will check that.
>
how about get_irq_desc_without_new()?

irq_desc_without_new()

YH

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Eric W. Biederman]

"Yinghai Lu" <yhlu.kernel@gmail.com> writes:

>>>
>>> - Introduce get_irq_desc and the functions or function modifications
>>>  that pass a struct irq_desc * into the genirq code.
>>>
>>>  Although I absolutely hate the name get_irq_desc as it implies we are
>>>  reference counting something and need a corresponding put_irq_desc.
>>>  Since the lifetime rules don't require that.  Please just call the
>>>  function irq_desc().
>>
>> will check that.
>>
> how about get_irq_desc_without_new()?
>
> irq_desc_without_new()

Possibly irq_desc_with_new() or even create_irq_desc in the one or two code paths that care.
Everywhere else can reasonably assume that the irq_desc entries have either been setup, or that
the irq number is invalid.

Eric

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Yinghai Lu]

On Wed, Aug 6, 2008 at 1:32 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
>>>>
>>>> - Introduce get_irq_desc and the functions or function modifications
>>>>  that pass a struct irq_desc * into the genirq code.
>>>>
>>>>  Although I absolutely hate the name get_irq_desc as it implies we are
>>>>  reference counting something and need a corresponding put_irq_desc.
>>>>  Since the lifetime rules don't require that.  Please just call the
>>>>  function irq_desc().
>>>
>>> will check that.
>>>
>> how about get_irq_desc_without_new()?
>>
>> irq_desc_without_new()
>
> Possibly irq_desc_with_new() or even create_irq_desc in the one or two code paths that care.
> Everywhere else can reasonably assume that the irq_desc entries have either been setup, or that
> the irq number is invalid.

will use irq_desc_with_new() toghether irq_desc()

YH

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Eric W. Biederman]

"Yinghai Lu" <yhlu.kernel@gmail.com> writes:

>> My suggestion for a non-breaking path:
>> - Kill NR_IRQS in then generic code.
>>  With Alan's serial patch and my kstat patch it looks like we have
>>  the worst of that.
>
> will use Alan's patch.at first.
> already reused your patch about kstat. and move kstat_irqs to irq_desc.

Part of what I am thinking is that there should never be a patch
that does s/NR_IRQS/nr_irqs/ that is just pointless noise.

Either we need a new abstraction like for_each_irq or to update the
code to the current best practices.

Which means the patches should be uncontroversial and mergeble on their
own with no weird dependencies.

Eric

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Yinghai Lu]

On Wed, Aug 6, 2008 at 1:35 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
>>> My suggestion for a non-breaking path:
>>> - Kill NR_IRQS in then generic code.
>>>  With Alan's serial patch and my kstat patch it looks like we have
>>>  the worst of that.
>>
>> will use Alan's patch.at first.
>> already reused your patch about kstat. and move kstat_irqs to irq_desc.
>
> Part of what I am thinking is that there should never be a patch
> that does s/NR_IRQS/nr_irqs/ that is just pointless noise.

for some platform like 32bit, may not like to mess up with
CONFIG_HAVE_SPARSE_IRQ, to have dyn_array to take small nr_irqs with
probing.

>
> Either we need a new abstraction like for_each_irq or to update the
> code to the current best practices.

already add for_each_irq_desc(irq, desc)...

| #ifndef CONFIG_HAVE_DYN_ARRAY
| /* could be removed if we get rid of all irq_desc reference */
| extern struct irq_desc irq_desc[NR_IRQS];
| #else
| extern struct irq_desc *irq_desc;
| #endif
|
| #define for_each_irq_desc(irq, desc)            \
|        for (irq = 0, desc = irq_desc; irq < nr_irqs; irq++, desc =
&irq_desc[irq])
|
|#else
|
|extern struct irq_desc *irq_descX;
|#define for_each_irq_desc(irqX, desc)           \
|        for (desc = irq_descX, irqX = desc->irq; desc && irqX != -1U;
desc = desc->next, irqX = desc ? desc->irq: -1U)
|
|#endif


>
> Which means the patches should be uncontroversial and mergeble on their
> own with no weird dependencies.

sure.

YH

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Alan Cox]

On Wed, 06 Aug 2008 13:35:55 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:

> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
> 
> >> My suggestion for a non-breaking path:
> >> - Kill NR_IRQS in then generic code.
> >>  With Alan's serial patch and my kstat patch it looks like we have
> >>  the worst of that.
> >
> > will use Alan's patch.at first.
> > already reused your patch about kstat. and move kstat_irqs to irq_desc.
> 
> Part of what I am thinking is that there should never be a patch
> that does s/NR_IRQS/nr_irqs/ that is just pointless noise.
> 
> Either we need a new abstraction like for_each_irq or to update the
> code to the current best practices.
> 
> Which means the patches should be uncontroversial and mergeble on their
> own with no weird dependencies.

A lot of these are range checks so could be replaced by a single
valid_irq(irq) test.

Alan

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> A lot of these are range checks so could be replaced by a single
> valid_irq(irq) test.

Yes.  My first impression was that with NR_IRQS dead valid_irq could
easily become. #define valid_irq(irq) ((irq) != 0) However thinking
just a little more since ultimately we will know which irqs have
something hooked up to them we might actually be able to say something
more interesting.  So I guess actually having a valid irq function
makes sense.  Instead of doing the idiomatic if (irq) logic inline.

Eric

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Alan Cox]

On Wed, 06 Aug 2008 18:02:18 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:

> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> > A lot of these are range checks so could be replaced by a single
> > valid_irq(irq) test.
> 
> Yes.  My first impression was that with NR_IRQS dead valid_irq could
> easily become. #define valid_irq(irq) ((irq) != 0) 

Not really - there are lots of cases where we sanity check an IRQ passed
from user space or module parameter configuration. So we do actually need

	valid_irq(irq)		((irq) > 0 && (irq) < nr_irqs)

[or relevant per arch alternatives]

Alan

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Yinghai Lu]

On Thu, Aug 7, 2008 at 3:12 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Wed, 06 Aug 2008 18:02:18 -0700
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>
>> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>>
>> > A lot of these are range checks so could be replaced by a single
>> > valid_irq(irq) test.
>>
>> Yes.  My first impression was that with NR_IRQS dead valid_irq could
>> easily become. #define valid_irq(irq) ((irq) != 0)
>
> Not really - there are lots of cases where we sanity check an IRQ passed
> from user space or module parameter configuration. So we do actually need
>
>        valid_irq(irq)          ((irq) > 0 && (irq) < nr_irqs)
>
> [or relevant per arch alternatives]

#ifndef CONFIG_HAVE_SPARSE_IRQ
#define   valid_irq(irq)          ((irq) > 0 && (irq) < nr_irqs)
#else
#define   valid_irq(irq)          ((irq) > 0)

anyway why 0 is invalid instead of -1U...?

YH


#endif

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[Alan Cox]

> #ifndef CONFIG_HAVE_SPARSE_IRQ
> #define   valid_irq(irq)          ((irq) > 0 && (irq) < nr_irqs)
> #else
> #define   valid_irq(irq)          ((irq) > 0)

For a sparse IRQ you might want to call an arch specific bit of C to do
the validating. Not sure that matters too much though as must user set
interrupts are ISA 8)

> anyway why 0 is invalid instead of -1U...?

So you can write the natural thing in C 

	if (!dev->irq)
		poll_device();

Re: [PATCH 00/33] dyn_array and nr_irqs support v4

[H. Peter Anvin]

Yinghai Lu wrote:
> 
> #ifndef CONFIG_HAVE_SPARSE_IRQ
> #define   valid_irq(irq)          ((irq) > 0 && (irq) < nr_irqs)
> #else
> #define   valid_irq(irq)          ((irq) > 0)
> 
> anyway why 0 is invalid instead of -1U...?
> 

Because 0 is easier to understand to a user when specifying in a module 
option.

	-hpa

[PATCH 00/33] dyn_array and nr_irqs support v4

[Yinghai Lu]

Please check dyn_array support for x86
v3: split changing to nr_irqs to small patches
    fix checkpatch error
    reorder the patch sequence to make dyn_array support go at first
        so could use that with arrays other than NR_IRQS
v4: add CONFIG_HAVE_SPARSE_IRQ with list to use condensed irq_desc array
    so could use 32 init, and init more if needed.

now: x86 32bit: have CONFIG_HAVE_DYN_ARRAY
     x86 64bit: have CONFIG_HAVE_DYN_ARRAY and CONFIG_HAVE_SPARSE_IRQ

left:
a. hook irq_2_iommu to irq_desc ?
b. expand /proc/interrupts to process > nr_irqs
c. expand to use irq > nr_irqs for msi

notes: may break some arch compling...

Thanks

Yinghai Lu