Subject: Re: Install failure on 1.5E
To: None <jchacon@genuity.net>
From: Nathan J. Williams <nathanw@MIT.EDU>
List: current-users
Date: 09/17/2000 01:37:27
<jchacon@genuity.net> (jchacon@genuity.net) writes:

> The problem is, is that I panic on bootup because wss is in GENERIC and hard
> coded to use irq10 (it's on 9 in the multia I beleive). The de card in these
> (pci based) is on 10 so the panic is over the kernel thinking both level and
> edge triggered cards are trying to share an interrupt.
> 
> Here's my questions:
> 
> 1. Is the goal of GENERIC that it should boot on as much as possible?

Close but not quite. It should also support as much hardware as
possible of the systems it boots on. A kernel that booted on more
systems but did less could be obtained by removing lots of drivers
(for example, you don't need audio to boot, os most USB drivers, or a
bunch of other stuff).

These goals do occasionally conflict.

> 2. If not, why install it as the basic kernel? The default kernel from an
>    install should work out of the box on as much as reasonably possible IMO. 

See above. "Work" is a vector, not a scalar parameter.

> 3. Why panic in the interrupt handler registration? Instead why not just
>    indicate a failure and abort the attach in some way?

If there were actually operating devices sharing an interrupt line,
but one was using level interrupts and one was using edge interrupts,
neither device would reliably work.

In the case of sound cards, you can usually finesse this, because they
won't spontaneously generate interrupts.

The code should probably do something like:

        register interrupt handler
        if (success)
                enable device; normal initialization.
        else
                disable device and prevent it from generating interrupts.

That last "prevent it from generating interrupts" is not something
that can be done, in general, so the low-level general-purpose
interrupt code should throw a fit if it thinks that one interrupt line
is being shared in an incompatible way.

To sum up: Devices which can be prevented from generating interrupts
should, ideally, be able to notice this conflict in their attach
routine and fail gracefully. The interrupt-handler establishing code
may not be up to that task, and not all devices will let you do that.

        - Nathan