public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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