Date: Fri, 13 Oct 1995 22:53:47 -0700 From: "Justin T. Gibbs" <gibbs@freefall.FreeBSD.org> To: Matt Thomas <matt@lkg.dec.com> Cc: Terry Lambert <terry@lambert.org>, hackers@freebsd.org Subject: Re: IPX now available Message-ID: <199510140553.WAA09554@aslan.cdrom.com> In-Reply-To: Your message of "Fri, 13 Oct 1995 18:16:36 -0000." <199510131816.SAA24191@whydos.lkg.dec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
>In <199510131819.LAA17947@phaeton.artisoft.com>, Terry Lambert wrote:
>
>> > probe ()
>> > {
>> > minimum to determin presence of hardware
>>
>> AND determine the allowable ranges for IRQ/DRQ/IO/memory this device
>
>Agreed. The probe routine should allocate no resources (such as VM) and
>no local state (ie. no private information for the driver's attach
>routines). It only provides information to configuration manager about
>the number of devices, and the ranges for the device. Note that for IRQ
>that not only the values should be supplied, but the types of IRQ that
>are supported (level, edge) as well.
Lets re-examine how the system might handle configuration:
1) Loop through LKMs and compile their resource and flexibility info.
Perhaps this can be combined with step four (the probe), but to
do it first gives us a data structure with all the devices that
*may* be in the system that the configuration manager can update
as probe information is returned.
2) PCI Bus Probe - Builds tree of PCI tags
3) EISA Bus Probe - Builds list of slot/ID pairs
4) Loop through LKMs a second time and call their probe routine.
The probe is responsible for "refining" the resource list
for this device by non-invasize means. For some ISA devices,
the probe may be a total no-op. For others, the drivers will
eliminate themselves, or find all of the information for the
devices they will attach to.
5) Loop through the LKMs in order determined by the configuration
manager calling the attach routines with the appropriate arguments.
An LKM that supports multiple buses may get loaded/unloaded many
times depending on the order of bus probing. A PCI or EISA probe
is not much more than a call to the "match" routine for each ID the
driver supports unless that driver can dermine additional
configuration info non-invasively.
Booting off a floppy could be real slow if we have to load and
unload the LKMs many times.
>Either via a smarter bootloader or a VM86 mode, calls into the BIOS
>to get configuration information should be done as well. For instance,
>getting the information out of the EISA CMOS should the DEPCA driver
>since the DE422 config registers are write-only.
This has always been on the wish list. If we ever get it, it should be
a standard EISA interface similar to the PCI Bios wrappers we have right
now. I would expect the interface to be used during the probe to refine
the device's configuration list.
>Also, the probe needs to be done once on a per bus-type basis;
>a probe should never try to all the different bus types at once.
Agreed.
>For PCI, I'm beginning in favor of having the driver call a pci_match
>routine to find instances of itself instead of the currently "passive"
>method. The passive method just doesn't lend itself to LKM.
This is the way the new EISA code is moving already.
>> > }
>>
>> meta_attach()
>> {
>> create a graph of "least relocatable" to "most relocatable"
>> determine desirable "location freeze" for each device
>> call per device attach with location information
I don't think that we can always have a "location freeze" at this point.
We can't determine the base addresses of all ISA devices safely which
is our main problem. The best we can do is get as much info as is
safe during the probe stage and build the list of attach attempts from
there.
>On the pci-sig mailing list, it seems many BIOS makers are putting in
>a Micro$oft configuration mode which only configurations "boot" devices
>and then expects the PnP O/S to call into the PCI BIOS to finish
>configuring all the other devices.
>
>For PnP devices that need configuring, the meta_attach is responsible
>for setting them to the proper drq/irq/port/memory/etc.
Fine. Flexible devices are easy. Its the devices that aren't flexible
that make our job hard.
>> > attach()
>> > {
>
>At this point in time, the configuration manager should have assigned
>(either dynamically if needed or statically if required) the port address,
>IRQ, and memory (and any other bus-specific resources). The driver should
>not have to pick anything at this point.
I don't think that this is realistic. If, for example, a device cannot
change its IRQ on the fly and cannot determine its current IRQ
non-invasively, we simply don't have the information until we're in
the attach. The configuration manager can "weed out" possible attach
attempts based on the results of earlier probes, but that still comes
down to specifying a few different port addresses for the driver to
look for cards at and the driver may have to determine the IRQ/DRQ/Maddr
if the ioport is correct. The best we can do is place these probes
after we have probed drivers that can determine their ioaddr non-invasively.
>> > Determin port Addresses
>
>At this point, the only the driver can do is either verify that the
>device exists at this address and is setup correctly.
Right.
>> > if (!reserve port address) {
>> > return some error code
>> > }
>> > Determine IRQ
>> > if (!Map IRQ Handler) {
>> > release port address
>
>Only if said port address was dynamically assigned to the device,
>if the port (or memory) address is fixed then that address should
>not be released.
Yes.
>
>Note that if there was a conflict, the configuration manager should
>have never bothered to call the attach routine.
Depends on your definition of probe. The probe just may not be sufficient
to know if there is a conflict or not.
>> The caveat on destructive probes (those involving triggering of interrupts,
>> like IN/Lance ethernet, etc.) is that they must be prevented.
>>
>> A destructive probe should be limited to a "add hardware mode". Just like
>> Windows 95: a user triggered event or an install triggered event that does
>> not repeat each boot.
>In my mind, if a user configures a device (such the probe and/or meta_attach
>is bypassed) and then the attach routine is called, the attach is allowed
>to do the equivalent of a destructive probe since it unconditionally owns
>those resources.
For ISA devices, you many times don't have a choice.
>The database created by the configuration manager and filled in by the probes
>and refined by the meta_attaches must be non-volatile and independent of the
>kernel. Note that this means that either the resource information in the
>config file disappears or config will need to able to write out a resource
>database file.
A driver's configuration information should be a portion of the driver
interface that can also be extracted from LKMs. Configuring a kernel
could be achived by a text file in the lkm directory that specifies the
lkms to load and optional attach information. This would have to be
handled by a third stage boot loader.
>The boot loader will need to able to read this configuration database and
>put it into memory along side the kernel image. Userconfig could then
>either stay in the kernel or become a separate entity. Actually, it might
>even make sense for userconfig to become the second-stage loader since it
>will have the proper information to do it.
I want the configuration database to built from data within the LKM at load
time. That way, a vendor can simply give you a binary to stick in your lkm
directory.
>
>Matt Thomas Internet: matt@lkg.dec.com
>3am Software Foundry WWW URL: <currently homeless>
>Westford, MA Disclaimer: Digital disavows all knowledge
> of this message
>
--
Justin T. Gibbs
===========================================
Software Developer - Walnut Creek CDROM
FreeBSD: Turning PCs into workstations
===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510140553.WAA09554>