> > 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)