There is no real standard, de-facto or otherwise, for what IRQ's are
used for internal modems for COM3 and COM4. This is especially true
because with the advent of more and more plug-and-play hardware. (And
it's never been true for PCMCIA cards; those use whatever IRQ's they can
find free.)
The right answer is not to make more compile-time configuration options
to the kernel, but rather to use a run-time configuration solution, such
as setserial. In the future, when Linux has hardware plug-and-play
support, that will be the far better (automatic) run-time configuration
solution, at least for those people with hardware that can support
plug-and-play operation.
For people who are loading the serial driver as a module, the solution,
as has already pointed out by others, is to use a post-install
configuration line in the /etc/conf.modules file to run setserial after
the serial driver has been installed. Again, this allows you to make
changes in your serial configuration without needing to recompile the
kernel.
The intent for CONFIG_SERIAL_SHARE_IRQ was NOT to allow for run-time
configuration of irq's, but rather to allow people who have hardware
which is *specifically* designed to allow irq sharing to use them. This
hardware is typically multi-port serial cards with 4-8 (sometimes 16)
UARTs, where the board has a TTL AND gate to tie the interrupt lines
together. (The reason why it is an AND gate instead of an OR gate is
because the interrupt lines on PC's are active low, not active high.)
Using CONFIG_SERIAL_SHARE_IRQ for hardware that was not designed to
specifically support IRQ sharing is done at your own risk. If you have
two boards using the same IRQ, it effectively means that you are tieing
the outputs of two TTL gates together. Since most modern boards use
tri-state logic, as long both ports aren't used at the same time, you're
OK. But if you do try to use both ports at the same time, when one
board tries to assert an interrupt by dragging the line low, and the
other board tries to keep the interrupt line high, the two TTL gates
basically end up "fighting" over the interrupt line, with one TTL
connecting the line to Vcc (i.e., the power supply), and the other TTL
gate connecting the line to ground. Why this is a bad idea should be
obvious. :-) The only reason why it doesn't fry the power supply is
the resistance in the TTL gates; the TTL gates do get warm, though. :-/
Usually, due to the uneven resistance levels, one TTL gate will
always "win", and the other will "lose". This means that one board's
interrupts will be recognized by the CPU, while the other one will not.
People who have managed to win in this situation are ones where the
modem's port has "won", and the mouse's port has "lost". Since the
mouse runs at a low baud rate, the serial driver's strategy to protect
against lost interrupts by setting timer timeouts allows some limited
functionality. It's really not something I can recommend as being good
for your hardware, though....
- Ted