When to burn those bridges

John Baldwin jhb at FreeBSD.org
Thu Sep 11 22:30:33 PDT 2003


On 11-Sep-2003 M. Warner Losh wrote:
> In message: <XFMail.20030911105053.jhb at FreeBSD.org>
>             John Baldwin <jhb at freebsd.org> writes:
>: I have thought about this as well, but instead of a placeholder flag,
>: just doing this for any driver that returned a probe value != 0.
>: This relies on very simple probes however, since ideally you would
>: want to execute the new driver's probe and if it matches better, then
>: you detach the old driver and attach the new one.   This requires
>: that the new driver's probe not try to alloc resources or dink with
>: the hardware though.
> 
> I've thought seriously about just detatching the older driver, if
> possible.  If that succeeds, we reprobe.  This has the advantage of
> being easy to implement, but does cause a fair amount of churn.

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.
 
> 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.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


More information about the freebsd-arch mailing list