> > 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.
>
That means we need two passes through the drivers. The first pass says
"find by looking at system information" and the second "find by peeking at
random memory addresses". Hmmm. Third pass "find by _writing_ to suspect
memory addresses". :-(
That way, all those probing drivers will note that the address range in
question is occupied.
> 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.
>
Right. Therefore, the configuration manager needs not be in the kernel at
all. A small "preconfigure this PnP card with these parameters and
initialize that driver with them" kernel command line parameter would be
sufficient.
The manager itself could then run like kerneld.
>
> 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.
>
It also means that the manager code needs to be in the kernel, even though
it's not used 99.9% of the time.
Frankly, I don't like that approach. The initial boot needs only a very
small number of devices which can be configured from the command line if
you don't want to boot with initrd. Anything else can wait.
> 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 :(
>
Right. (Basic support, at least.)
> 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
IMHO, this should be turned on its head:
2. PnP driver initializes.
3. All drivers register themselves.
4. PnP driver sets up the drivers with config values from the command
line (first pass, above).
5. PnP driver calls all the probe functions repeatedly (second and third
pass, above).
>
> 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.
>
Hmm. You now have two mechanisms for configuring a driver (callback and
request-this-config-now). I'd do this differently.
- Let every driver register a probe function which finds as many instances
of its hardware as it can. The driver says to the config manager "I have
found this hardware there". Let every driver register a callback which
just means "Your configured device X is here". Let legacy drivers
register a callback "Configure your device to use THIS set of resources.
If you can't, tell me what the resource list should look like".
Most legacy drivers have this code mixed up in one big probe function.
- After each pass, the config manager resolves any conflicts. This is still
easy because the device drivers aren't actually running yet.
- The device gets a callback with the actual values and can immediately use
them.
This means that the number of devices a given driver supports under this
scheme is anywhere from zero to *whatever*, and that the list of devices can
change at runtime. This is important for PCMCIA. Or for two drivers which
mediate access to one piece of hardware (parallel port; floppy interface).
This also means that the actual device driver and the code which probes or
configures the device can be different modules. IMHO, this is a Good Thing,
as it reduces the amount of dead code in the kernel.
-- People are beginning to notice you. Try dressing before you leave the house.-- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click <A HREF="http://info.noris.de/~smurf/finger">here</A>. 42