Dont get me wrong, obviously everyone wants a proper solution to this,
but a kludge isnt as impossible as you make out...

>...and then it's a burned mib number for all eternity.  (Our current
>sysctl interface doesn't allow mib nodes to be relcaimed.)

So we burn one mib number.  If you're worried about that, we could
burn an identifier on "hw.io", and another one on "hw.io.pcmcia".
(Some io-bus mib entries might be worthwhile anyway, to let the user
check how they setup the PCMCIA boot-time UI to configuration, when
it arrives.)

>Also, it's MI code, and the problem exists on other architectures.  (No,
>really.)

Sure, if the problem lies with pcic not decoding some lines or with
weirdo/unsupported devices like the neomagic.

But _if_ we contemplate the hack (and maybe not, if Ken is standing up
to a proper solution): document the kernel variable whcih actually
controls the mask as being an MI part of the pcmcia interface.  Any
port with PCMCIA will provide and honour the irqmask variable.  Any
port which needs the kludge can frob the irqmask variable via the
sysctl.  (IO port blacklists or mask/match pairs -- bletch.)

Aren't we really arguing about whether this is _so_ painful that it
justifies a kludge -- a kludge that's just enough to let users install
far enough to build their own kernel -- until we have a real solution?
What's an average laptop owner (who probably doesnt want to track
-current) sposed to do?  `Wait for 1.4' or use some other OS?