"Robert.V.Baron" writes:
> This isn't rocket science.  Modify the irq allocator to not allow use of
> certain irq's.

Bob:

1) It isn't just IRQs. I/O ports are also impacted here. There is no
   single set of I/O ports that are consistantly used by all sound
   devices, etc. for example.
2) We have a clean fix, but it is going to take a month to
   implement. That means it *will* be in 1.4 (which is scheduled for
   late spring) but will not be in 1.3 (which goes to final cut within
   24 hours or so.)
3) Release engineering is an art more than a science, but one
   important rule is "make no major changes 24 hours before the
   release". We've been aware of the PCMCIA problem for a while, but
   we've failed to get a solution done on time. The choices are...

   a) delay 1.3 for months -- not just PCMCIA users, but all the
      people who want things like fixes for literally thousands of
      bugs.
   b) risk the whole release with last minute hacks, endangering the
      whole ball of wax.
   c) document the problem, and treat PCMCIA stuff like it isn't quite
      baked, which I'm afraid it isn't. (Once it works its fine, but
      getting it going is overly tricky.)

> If you are opposed to this on general principles, then at least pass
> a #define constant down to the pcmcia saying that you are building a
> boot kernel and it should use a restrictive set of irq's.

Were it only IRQs, it might be okay, but as I've noted, unfortunately,
i/o ports are also impacted here. The whole thing is an unfortunate
mess, and I'm not proud of it. However, we have very little choice.

If it is any consolation, we will be trying to get sysinst to help
deal with the situation so users of PCMCIA can kludge themselves an
install with it.

Perry