Date: Tue, 23 Nov 1999 10:28:46 +0100 (CET) From: Nick Hibma <hibma@skylink.it> To: Doug Rabson <dfr@nlsystems.com> Cc: FreeBSD Newbus Mailing List <new-bus@FreeBSD.org> Subject: Re: cvs commit: src/sys/pci pcisupport.c pci.c Message-ID: <Pine.BSF.4.20.9911231015440.627-100000@henny.jrc.it> In-Reply-To: <Pine.BSF.4.10.9911230907510.318-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > The reason for them being there in the first place is that every > > > motherboard comes with USB kit and this way it looks more pretty (peter). > > > The real solution will be to define some method of detaching a driver > > > after it has attached. > > > > Duh, detaching a __stub__ after it has attached. > > Probably we will track the priority which a driver probed at and if it > wasn't zero, detach the driver when a new driver is loaded, before the > reprobe. This would allow the new driver to bid for the hardware. You'll get an awefull lot of disconnects in that case (1). It would be highly inappropriate in the case of USB, disconnecting the Zip drive if you load the mouse driver. Requesting the maximum priority at which the driver might attach is the minimum you can do to avoid detaches.(2) It would be even better if you could first do a non-intrusive probe on _possible_ targets before detaching them (3). I've been playing with the idea of cloning devices (if DEVICE_REPROBABLE returns true) and probing on those clones. The only problem I had was that I had no clue on where to stick those clones. Maybe we should create a new device with the same ivars and make it quiet during the reprobe instead of a clone. foreach(devclass_get_devices(dc)) if (DEVICE_REPROBABLE(odevice) ndevice = clone_device(odevice) # or ndevice = devclass_add_device(dc) # and copy ivars, resources. priority = DEVICE_PROBE(ndevice) if (priority > device_get_priority(odevice)) # or was it <? DEVICE_DETACH(odevice) devclass_delete_device(ndevice) if (DEVICE_PROBE(odevice)) DEVICE_ATTACH(odevice) endif endif endif endfor I think your best bet (without the fancy detachment scheme you proposed some weeks ago (to me or the list, can't remember) implemented) is to track a priority DEVICE_PRIORITY_STUB and only detach those before you start probing (4). Or make it possible for a stub to fail the attach phase silently (ESTUB) (5). Cheers, Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.20.9911231015440.627-100000>