When to burn those bridges

[Doug Rabson]

On Fri, 2003-09-12 at 08:39, M. Warner Losh wrote:
> In message: <XFMail.20030912013027.jhb at FreeBSD.org>
>             John Baldwin <jhb at freebsd.org> writes:
> : How do you know which drivers to detach?  Are you going to detach
> : the generic PCI ATA driver on every kldload?  Are you going to
> : detach the generic PCI-PCI bridge driver for PCI-PCI bridges on
> : add-on cards for every kldload of a PCI driver?  That would be
> : freaking insane.  The problem is that you don't know what devices
> : a new driver might be more suitable for than existing drivers.
> 
> This does suck.
> 
> : > Besides, proble routines on self enumerating devices should look at
> : > the IDs that anybody can look at at any time.  However, there are some
> : > issues with some drivers that have old/new versions or that need to
> : > ask the hardware what kind of thing it really is before making the
> : > call.  These drivers are rare, thankfully, and even rarer are those
> : > that have different levels.  owi/wi is the only one I know of that
> : > fits this bill, and the only reason owi is there is to help fix wi, so
> : > I don't think we should necessarily design to make this sort of thing
> : > too easy....
> : 
> : rl(4) and re(4)?  Several drivers still allocate resources in probe(),
> : which would break things.
> 
> yea, but that's a bit of a pathological case.  first, rl/re attach to
> a specific driver, and not override.  So maybe we could mandate that
> drivers that are generic and return negative return values should be
> constrained to only look at the plug and play info and are not allowed
> to look at resources.  owi/wi is the only pair that does this
> evilness.

This is why I was thinking about a device flag which a driver would set
if it is just a placeholder which can be pre-empted safely.