lkml.org 
[lkml]   [2007]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] killing the NR_IRQS arrays.

    * Eric W. Biederman <ebiederm@xmission.com> wrote:

    > So I propose we remove all assumptions from the code that we actually
    > have an array of irqs. That will allow for irq_desc to be dynamically
    > allocated instead of statically allocated saving memory and reducing
    > kernel complexity.

    hm. I'd suggest to do this without changing request_irq() - and then we
    could avoid the 'massive, every driver affected' change, right?

    i.e. because we'll (have to) have an nr_to_desc() and desc_to_nr()
    mapping facility anyway, lets just not change the driver APIs massively.
    There dont seem to be that many drivers that assume that irq_desc[] is
    an array - are there?

    otherwise, in terms of the irqchips infrastructure and the API between
    genirq and the irqchip arch-level drivers, this change makes quite a bit
    of sense i think.

    or am i missing something fundamental?

    Ingo
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-02-16 13:47    [W:3.498 / U:0.748 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site