From: ebiederm@xmission.com (Eric W. Biederman)
To: "Yinghai Lu" <yhlu.kernel@gmail.com>
Cc: "Ingo Molnar" <mingo@elte.hu>,
"Thomas Gleixner" <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org,
"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
Date: Thu, 14 Aug 2008 16:55:32 -0700 [thread overview]
Message-ID: <m17iajb18r.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <86802c440808141342k6cb0dc59ud067018b0a171232@mail.gmail.com> (Yinghai Lu's message of "Thu, 14 Aug 2008 13:42:48 -0700")
"Yinghai Lu" <yhlu.kernel@gmail.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
next prev parent reply other threads:[~2008-08-15 0:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1218705441-21838-1-git-send-email-yhlu.kernel@gmail.com>
2008-08-14 13:26 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Ingo Molnar
2008-08-14 13:31 ` [PATCH] irq: sparse irqs, fix Ingo Molnar
2008-08-14 13:36 ` [PATCH] irq: sparse irqs, fix #2 Ingo Molnar
2008-08-14 16:33 ` Andrew Morton
2008-08-14 17:03 ` Eric W. Biederman
2008-08-14 13:53 ` [PATCH] irq: sparse irqs, fix IRQ auto-probe crash Ingo Molnar
2008-08-14 13:57 ` [PATCH] irq: sparse irqs, export nr_irqs Ingo Molnar
2008-08-14 14:07 ` [PATCH] irq: sparse irqs, fix #3 Ingo Molnar
2008-08-14 17:34 ` Yinghai Lu
2008-08-14 19:01 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Yinghai Lu
2008-08-14 20:05 ` Eric W. Biederman
2008-08-14 20:42 ` Yinghai Lu
2008-08-14 21:24 ` Yinghai Lu
2008-08-15 0:11 ` Eric W. Biederman
2008-08-15 0:49 ` Yinghai Lu
2008-08-15 1:01 ` Eric W. Biederman
2008-08-15 1:41 ` Yinghai Lu
2008-08-15 2:33 ` Eric W. Biederman
2008-08-15 1:09 ` Eric W. Biederman
2008-08-14 23:55 ` Eric W. Biederman [this message]
2008-08-15 12:18 ` Ingo Molnar
2008-08-29 21:16 ` Andrew Morton
2008-08-29 21:43 ` Yinghai Lu
2008-08-29 21:49 ` Andrew Morton
2008-08-29 21:54 ` Yinghai Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m17iajb18r.fsf@frodo.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=yhlu.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox