linux-kernel - Re: [PATCH 00/53] dyn_array/nr_irqs/sparse

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: <m17iajb18r.fsf@frodo.ebiederm.org>
Date:	Thu, 14 Aug 2008 16:55:32 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Yinghai Lu" <yhlu.kernel@...il.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10

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

> On Thu, Aug 14, 2008 at 1:05 PM, Eric W. Biederman

>> What I wound up using in my tree is a little different.
>>
>> I introduced an opaque/empty structure: struct irq to be used in places
>> where we need pointers instead of an integer irq number in the interfaces.
>>
>> I have a version of the genirq api that works on struct irq instead of
>> unsigned int irq.
>>
>> I have functions:
>> struct irq * to_irq(unsigned int nr);
>> struct irq_desc *to_idesc(struct irq *);
>> unsigned int irq_nr(struct irq *irq);
>
> struct irq {
>   unsigned int nr;
>   struct irq_desc *idesc;
> }

I did:
  struct irq_desc {
  	struct irq irq;
        ....
  }
  Then to_idesc is just a container_of call.  Or simply a type cast but
  that is rude.

Having nr be a field in struct irq is possibly valid.

When last we talked about the design Linus was emphatic that what gets
exposed to drivers be an opaque token.  When I looked for 99%+ of the
arch code we can use that same opaque token.  irq_desc is something
we don't really care about except in do_IRQ().

So I guess the truly important thing is that struct irq is not
ultimately available in a usable form to drivers.

We seem to give drivers access to everything when they include interrupt.h
So I'm not certain how strict we can succeed in being still is a good goal
to aim for.

>> Is there any reason why the migration path for architectures can not be:
>> Until they are converted:
>> #define NR_IRQS and use the irq_desc array.
>>
>> If they are just using a dynamically allocated array.
>> #define NR_IRQS nr_irqs
>>
>> Once we kill the array entirely.
>> #undef NR_IRQS or
>> #define NR_IRQS 0xfffff000
> why not use -1U here?

So that negative error codes continue not to be valid irqs.

In most places irq is an unsigned int so it may safely be used to index irq_desc.
In other paces people are sloppier and used a signed value so they can return
negative error values.   create_irq() on x86 is one of those places.  There
is also platform_get_irq.  and possibly a few others.

Eric

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