Date: Wed, 20 Dec 2000 02:24:23 -0800 From: Mike Smith <msmith@freebsd.org> To: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> Cc: freebsd-hackers@freebsd.org Subject: Re: Request for comments: ISA_PNP_SCAN() (long) Message-ID: <200012201024.eBKAONQ16277@mass.osd.bsdi.com> In-Reply-To: Your message of "Wed, 20 Dec 2000 19:05:12 %2B0900." <200012201005.TAA04607@zodiac.mech.utsunomiya-u.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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.
>
> Um, may be my wording was not appropriate. I didn't mean dynamic or
> active scanning of devices. Rather, I just wanted to have a routine
> to enlist PnP device instances hanging from the ISA bus, so that the
> hinted device will abondan its probe if there is a PnP
> sibling; no active scanning, probing, poking, or whatever, is
> involved and inteded.
No, I understand what you're trying to do. It just doesn't work like
that. You have no idea, for example, whether the PnP ID you find
somewhere else would actually have been "won" by you or not.
The right solution is to make the probe order correct, then none of the
rest of this is an issue.
> >This is a known, longstanding bug in the current ISA bus implementation,
>
> I knew.
>
> >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.).
>
> How do we supposed to classify PnP devices into two groups?
The disable method should return failure when you try to disable the
device.
> >With these probed
> >first, the hints are typically going to be ignored.
>
> So long as we have two device instances, a hinted instance and a PnP
> instance, for a single ISA device, the hinted instance will fail
> (rather than ingored), after the PnP instance succeeds (unless the
> hinted device instance is disabled or deleted).
The hinted instance should fail, yes. It should fail *quietly* during
the probe phase when it discovers that it can't allocate the resources
from the hint because they're already allocated.
> While the above scheme generally sounds good, we will still have a
> numbering problem, won't we? Hinted devices created by the isahint
> driver have the unit number 0 (because they are listed as such in
> /boot/device.hints), then the PnP instance for "foo" will have the
> unit number 1 when it attaches.
It shouldn't work like this, no. The hinted device should only get the
unit number if its probe succeeds (but it may not work like this yet, I
admit). There may be a need for arbitration for unit numbers at some
point.
> This is quite analogue to what I trid to fix by introducing
> ISA_PNP_SCAN/PICK/FIND(), which should be useful for the
> hinted/non-PnP instance to give way to its PnP counterpart.
The fundamental problem here is that it's not possible to associate a
driver with a device until after the entire probe process has completed,
so the whole "find my PnP shadow" concept just can't work.
> >This is not (IMO) the correct solution. The bugs above should be fixed
> >instead.
>
> Did you see my last code example in which non-PnP/hinted device
> instance will give way to the PnP instance?
Yes. It still doesn't work. 8(
> At least we are agreeing that there are two problems/bugs to be fixed
> :-)
I've been trying to get these fixed for years. I hate ISA. 8)
--
... 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012201024.eBKAONQ16277>