lkml.org 
[lkml]   [1996]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: PNP patch into kernel when?

    On Thu, 5 Dec 1996, Andrew E. Mileski wrote:

    > > A major one for me that you gain doing it right is
    > > - Boards can now get told 'I really would like you to switch IRQ'
    > > as some can do that if asked nicely.
    > >
    > > Alan
    >
    > That is planned actually, but it is really a part of the PnP stuff
    > (configuration mechanism).

    And it's also _very_ difficult to get your head around. (I've started
    writing a basic Config Manager [kernel-based] to bolt onto Andrew's PnP
    code). Basically, any device which can change IRQ, etc., by a non-standard
    interface should register itself as a 'Legacy' device (others don't need
    to bother).

    Writing an _intelligent_ config manager is a complete nightmare!

    So... my question is: should we:-

    a. Make PnP stuff _required_ (but only one subsystem required -
    legacy), or
    b. Put the configuration manager as part of the resource-manager

    I can't really decide, although thinking in terms of a more generic and
    upgradable way to do it, b seems to be the best, but that means that PnP
    'Legacy' support (from user-side as part of generic PnP listings) might
    get a bit complicated. IMHO, we should get the resource manager patches in
    ASAP, but if we need to add hooks to do the above, we might need to defer
    it a bit.

    Problem: if we can now support 'intelligent' resource re-allocation,
    imagine this situation:-

    * Drvier for Card A has allocated IRQ 5 (via PnP or some other
    mechanism)
    * Card B has no method of autoconfiguring, and the driver wants to
    probe an IRQ. Unfortunately, it is using IRQ 5, which does not
    get probed, because it is already allocated. So, the IRQ
    reallocation code never gets used anyway with cards that cannot
    read their IRQ from config registers, and therefore probably
    support dynamic reconfiguration anyway!

    Should we modify the IRQ-probing code to work around this?

    As for the config manager itself, here is my approach (any comments
    definitely welcome):-

    * Anything already configured should be avoided being reconfigured
    if at all possible
    * Reconfiguration if needed should go for the option which
    re-configures the least resources.

    As a side point, is it worth implementing a much more complex
    configuration manager as a user-side daemon, and have a very simple
    configuration manager in the kernel itself?

    --
    Tom Lees <tom@lpsg.demon.co.uk> http://www.lpsg.demon.co.uk/
    PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
    finger tom@master.debian.org for full public key (also available on keyservers)


    \
     
     \ /
      Last update: 2005-03-22 13:38    [W:0.019 / U:1.604 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site