> Well, these kinds of issues have been dealt with in the kernel before...
> Lots of cards behave badly when other drivers probe in their space. (I.E.
> NE2000 clones)
But you have to probe for other 8390-based cards first, because other
(non-NE2000) 8390-based cards can easily look to the NE2000 driver like a
bad clone, and thus get allocated to the wrong driver. NE2000 is probably
the worst effect, although I wouldn't like to have an autoprobe touch
ports that are connected to a live IDE or SCSI drive.
So, we should find devices in the order that will reduce the
possible catastrophic effects as much as possible - probably things like
IDE and SCSI first, then Network stuff (non-NE2000 8390-based cards first,
NE2000 driver next, others follow), serial, and the like, then other
misc devices like sound cards.
> The whole idea is to probe in the correct order:
> Ancient, fixed IO devices.
> Semi-programmable devices.
> PnP Devices.
Unfortunately, this isn't entirely possible. Some cards which do support a
semi-programmable mode (for example SB16 cards) look _EXACTLY_ the same as
other cards which _DON'T_, and therefore use the same driver.
> > Should we modify the IRQ-probing code to work around this?
> Well, on startup no. The problem comes with modules...
That's assuming that probing is done in the 'right' order... something
that's not always possible.
> On startup, unless you have a device conflict between fixed IO devices, you
> shouldn't have a problem if you probe in the proper order. However...
>
> If you compile a fixed resource card (say, soundcard) as a module:
> Startup - the resources of the soundcard are not allocated, so a PnP card
> gets the IRQ the card wants.
> After booting, you try to probe for the card, but since the IRQ (or io, or
> whatever got taken) isn't available, it isn't detected.
>
> Options:
> A) append "reserve IO=0x???-0x???,IRQ=?,DMA=?" to the kernel.
Doesn't this affect the modules as well? That just means that _NOTHING_
will be able to use the space.
> B) allow modules autoprobe to "look under" softconfig/PnP cards for fixed IO
> cards.
The user-space configuration manager (or boot-time pre-supplied config)
would be able to handle this.
> > 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?
>
> Yes... definatly. The question is how do you put that kind of information
> back into the kernel (for later reboots) Hmm... For autoconfig, we have
> an interesting scenario... since there is a simplistic configuration manager
> in the kernel itself, it may not be able to handle some complex cases of
> softconfig cards/fixed cards... So how do we get the system into a state where
> the userspace manager can run?
We can always assume that an initrd and basic fs/exec code can run - even
if we have no media hardware configured at all. Therefore, the initial
config can be done from an initrd using the user-space config daemon, and
then the 'linuxrc' script can pass on to the (now configured) boot device
to use.
> I think when the kernel is dealing with devices it needs some help...
> flag things like SCSI and video IO_ESSENTIAL... so if there is a conflict
> between your sound card and your scsi controller the SCSI wins, and the
> userspace program can then deal with the complex re-arrangements.
I think that only "vital" drivers should directly request allocation of
PnP devices when compiled into the kernel. Other drivers can instead
register "configuration" functions, which get called when the resource is
actually configured by whichever configuration manager (user or kernel).
> Then once re-arranged, the userspace program may need to reboot for softconfig
> devices... so then how does it get that information back to the kernel?
Assuming after this we have the capability to use these storage devices,
we can create an initrd with a 'linuxrc' which starts the user-space
configuration daemon.
> Looks like there may need to be a resources file that lilo/loadlin etc can
> give to the kernel.
Unfortunately, this sort of upgrade takes a long time to permeate through
to all the various bootloaders (syslinux has only just added support for
bzImage+initrd). However, it is, IMHO, a more superior way of doing
things, than to use initrd.
OTOH, an even better way of doing it may be to use the 'setup sectors'
(are these i386-specific? - I haven't looked). This avoids having to make
any additions to already bloated bootloaders.
I think the way the initialization sequence should look is something like
this:-
1. Kernel checks for various bus types (PCI, SBUS, etc.) From this point
of view, it would be nice if PCMCIA was part of the kernel, and not a
module :(
2. PnP driver is initialized, and either:-
a. disables _ALL_ PnP devices it can, or
b. loads the preset configuration from whatever method
3. Standard device drivers load. Possibly critical drivers, such as SCSI,
and IDE, allocate and initialize PnP devices they can control. Other
drivers, without bothering to look for any PnP drivers, register a
'configuration function' with the PnP code. Devices which can
reconfigure themselves, although not through the PnP interface also
register themselves during this initial detection phase.
4. PnP config manager configures all the remaining PnP devices if it can,
but doesn't bother doing any intricate checking - it simply loops
through the cards, one by one, configuring each one it can.
'configuration functions' registered earlier are called where
appropriate. This ensures the maximum feasible functionality for the
user who does not have the user-space configuration daemon.
5. Initial boot takes place (possibly on initrd).
6. User-space configuration manager (or user) decides how to configure
everything, and saves this. If a reboot is necessary, it is done.. This
should be done from the boot scripts, before _any_ modules are loaded.
7. Modules are loaded. Modules request PnP devices to be configured,
rather than registering themselves to be called back, as in the boot
process, and immediately receive the configuration given.
8. If running on initrd up to here, the main root device is switched to,
and startup continues.
-- 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)