Messages in this thread |  | | Date | Sat, 7 Dec 1996 15:50:16 +0000 (GMT) | From | Tom Lees <> | Subject | Re: PNP patch into kernel when? |
| |
On Fri, 6 Dec 1996, Dan Merillat wrote:
> 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)
|  |