> This is to propose a new ISA bus method to sys/isa/isa_common.c.
> The new method is to enumerate PnP device instances matching the
> specified PnP IDs. (Well, may be this is a kludge after all.)
>
> device_t ISA_PNP_SCAN(device_t bus, struct isa_pnp_id *ids, int *n);
>
> It will return the (n + 1)th instance of the given PnP IDs on the
> specified ISA bus. You set -1 to n to obtain the first PnP instance
> matching the given PnP IDs and can enumerate all matching instances
> by calling ISA_PNP_SCAN() until it returns NULL.
This sort of active scanning for devices does not interact well with the
way that our current bus architecture works. In particular, it makes it
very difficult to implement the "bidding" process that allows us to have
several drivers which might support the same device.
> The trouble is that we always need to have hints for this driver in
> /boot/device.hints for those systems without a PnP BIOS. Then, the
> isahint driver will create a device instance. The pnpbios driver will
> create a PnP device instance separately if the PnP BIOS exists and
> reports the presence of a device.
Yes. This is intentional.
> Problem 1:
> In -CURRENT the non-PnP device instance is probed first. If this is
> successful, it will become available to the system as the 'foo0'
> device. Probe on the PnP device instance will fail in this case
> because the resources for this device has already been claimed by the
> non-PnP device instance, and the user will see erroneous boot message
> "unknown: <PNP####> cannot assign resources".
This is a known, longstanding bug in the current ISA bus implementation,
and it needs to be fixed. The correct ordering requires sorting the PnP
devices into two classes; those which can be configured/disabled, and
those which cannot.
- Enumerate all PnP devices.
- Disable PnP devices which can be disabled.
- Probe/attach PnP devices which cannot be disabled.
- Probe/attach ISA-hinted devices.
- Probe/attach remaining PnP devices.
This actually works better than expected because the PnP devices that
most people are upset about conflicting with the hints are devices which
can't be disabled (eg. onboard serial ports, etc.). With these probed
first, the hints are typically going to be ignored.
> Problem 2:
> If the non-PnP device instance fails probe (because device hints are
> wrong), the PnP device instance will succeed (because its resource
> description is supposed to be correct). The PnP device instance will
> become available in the system as 'foo1', rather than 'foo0'. This is
> because the non-PnP device instance wasn't deleted after its probe
> failed.
This is also a bug, and fixing it would be desirable. If a probe based
on hints fails, the hints are clearly invalid.
> To avoid the second problem, we may prepare two separate drivers for
> non-PnP and PnP device instances as follows.
This is not (IMO) the correct solution. The bugs above should be fixed
instead.
Regards,
Mike
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
