From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 31 10:01:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CE2E16A4CF for ; Wed, 31 Mar 2004 10:01:38 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9A5143D31 for ; Wed, 31 Mar 2004 10:01:37 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i2VHxUUS052296 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 31 Mar 2004 19:59:33 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i2VHwIhn050418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2004 19:58:18 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id i2VHwH3j044439; Wed, 31 Mar 2004 19:58:17 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i2VHwEMC044438; Wed, 31 Mar 2004 19:58:14 +0200 (CEST) (envelope-from ticso) Date: Wed, 31 Mar 2004 19:58:14 +0200 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20040331175813.GA44049@cicely12.cicely.de> References: <20040330.014632.132641792.imp@bsdimp.com> <20040330090601.GE32646@cicely12.cicely.de> <39883.134.148.20.33.1080706267.squirrel@134.148.20.33> <20040331.093211.102577197.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040331.093211.102577197.imp@bsdimp.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cicely12.cicely.de cc: ticso@cicely12.cicely.de cc: samuel.lawrance@studentmail.newcastle.edu.au cc: boris@brooknet.com.au cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de Subject: Re: usbd config file parse behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 18:01:38 -0000 On Wed, Mar 31, 2004 at 09:32:11AM -0700, M. Warner Losh wrote: > : I agree that it's bad to yank a device from under ugen automatically and > : reattach it to a better match. > > I think it is good. Really. However, ugen should mark the device > busy when it is opened, and mark it as unbusy as closed and the > reprobe shouldn't happen if the device is busy. Otherwise, there's no > harm. ugen2 goes away, who cares. ugen0, ugen1, and ugen3 would > still be there. However, if a device is in use, the probe routines of > other divices may interfere. ugen has a busy flag in his softc. > Part of the problem is we can't tell a driver 'detach if you aren't > busy' vs 'detach now, your hardware is gone or about to be gone'. > Maybe we should fix that at the same time. There's also a desire from > the hot-plug bus people to have a 'quiesce' the device, which is > similar to the current suspend method, but with different semantics > (quiesce means stop using the hardware, while suspend says put the > hardware to sleep). Yes - a generic way would be best. And of course reprobe is not everything. In the USB as well as in the hot-plug PCI case there is a need for functions to disable/enable ports/slots manually - I think that fits with what you mean by 'quiesce'? If someone with more knowledge about the generic part could implement this then I could do the USB specific part. > : How about adding a new ioctl on /dev/usb, eg USB_REPROBE to reset a device > : if a better match exists? > > I don't want this to be USB specific. usb has enough kludgy hacks. > That's why we're in this mess. If we do something like this, then we > should do it for all devices on all busses. > > : Could tack an option on to usbdevs to call it on requested devices. > > Absolutely not. We want uniform behavior. It would be a nightmare to > manage a huge table in the kernel with exceptions. usbdevs is not the right tool for this kind of functionality anyway. devinfo -v with the usb devd support is already more generic then usbdevs. Meating up the informations is simple once there is no static size limit. A userland tool for reprobe should be named more like devctl and be able to operate on the whole device tree. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de