[lkml]   [2008]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
    "Yinghai Lu" <> 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.


     \ /
      Last update: 2008-08-15 02:07    [W:0.046 / U:15.004 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site